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

[Volker Grabsch]

Tony Theodore schrieb:
> On 22/10/2013, at 5:20 PM, Volker Grabsch <address@hidden> wrote:
> 
> >>> However, that might be too much of a hack, so I
> >>> prefer the "i686-pc-mingw32.static" style.
> >> 
> >> Only problem with the "vendor" segment is that gcc apparently uses *-w64-* 
> >> to enable features.
> > 
> > If that's the only issue ... can we tell GCC to
> > always enable/disable the "*-w64-*" features,
> > independent from the actual "vendor" segment?
> 
> They're not so much features as internal build rules like instruction sets 
> and directory layouts that we'd have to know about and keep track of. These 
> are sometimes specified as "i[[3456789]]86-w64-mingw*)" and "*-w64-mingw*" so 
> there's really no good way around it. At least they don't hard code mingw32 
> so it's possible in the future that the confusing x86_64-w64-mingw32 can be 
> changed - other than many other build systems do look for mingw32. All in 
> all, it seems easier to use the canonical triplets with suffixes.

Thanks for the explanation. So let's stick to
the "i686-pc-mingw32.static" style.

> >> The $(MXE_CONFIGURE_OPTS) variable takes care of a lot
> 
> The MXE_CONFIGURE_OPTS sets the host, build, prefix, 
> [dis|en]able-[shared|static] options, but now I'm wondering if that makes the 
> build rules too opaque. Take a look at expat[1], is that concise or obscure?
> 
> [1] https://github.com/tonytheodore/mxe/blob/shared-using-target/src/expat.mk

When I wrote the first versions of MXE, I decided against
such a variable, so the build rules are more explicit.

However, over the years more and more special stuff
accumulated, e.g. to fix builds on specific platforms.
So we had to apply those fixes to many packages. If we
forgot one and the package or platform are rarely used,
it would have been only noticed at the next testing
phase.

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.

The other extreme would be to create these kind of
abstractions beforehand, when there were just a handfull
of packages. These kind of abstractions are almost
certainly unsuitable, especially on a project like MXE,
where we one needs some time and experience to find
the "good" abstractions. This can lead to abstractions
into which non-fitting packages would somehow have to
be pressed.

But as I said, I think $(MXE_CONFIGURE_OPTS) clearly
belongs to the former kind of abstrations, not the
latter one.


Regards,
Volker

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