Re: [Mingw-cross-env-list] Status of build with shared libraries

[Volker Grabsch]

Tony Theodore schrieb:
> On 22 Oct 2013, at 11:28 pm, Volker Grabsch <address@hidden> wrote:
> > 
> > Thanks for the explanation. So let's stick to
> > the "i686-pc-mingw32.static" style.
> 
> Should we let “i686-pc-mingw32” be an alias for “i686-pc-mingw32.static” so 
> that minimal changes are required to existing downstream build scripts? This 
> way, there’s always a default build and users can choose different variants 
> as required.

This sounds reasonable. We shouldn't break backwards
compatibility without a really, really good reason.

However, I still prefer to establish default settings
via documentation rather than code, so everything
remains explicit. Thus, the tutorial and all other
documentation should be adjusted to the new notation
(i686-pc-mingw32.static).

The aliasing from i686-pc-mingw32 to i686-pc-mingw32.static
should happen at a central place in the main Makefile.
It should produce a deprecation warning such as:

| Warning: Deprecated target name "i686-pc-mingw32"
| specified. Using "i686-pc-mingw32.static" instead.

(This is just a quick proposal from my head. Feel free
to reword this warning message as you see fit.)

Note that a deprecation message usually implies that
some feature will vanish soon. In this case, however,
we aren't in a hurry. So this alias may remain well
for years, if not forever.

Nevertheless, we should show this warning message so
that users who care about cleanliness that are reminded
to make their scripts more explicit.

> > […]
> > So all in all, I agree that $(MXE_CONFIGURE_OPTS) makes
> > a lot of sense and has more advantages to the quality
> > than disadvantages.
> > 
> > Also, I think it is important to consider _how_ an
> > abstraction develops. This one occurred after lots of
> > redundant ./configure options and somehow had to stay
> > "in sync" (in the sense described above). So we had
> > real-world working code, found a pattern, and abstracted
> > it. This is a good thing.
> 
> Thanks, I hadn’t thought of _how_ abstractions develop - it explains many 
> issues I have with IT projects.

Hehe. :-)


Regards,
Volker

-- 
Volker Grabsch
---<<(())>>---