Re: [Mingw-cross-env-list] VENDOR in host triplet (was mingw-w64 and mingw-cross-env)

[Volker Grabsch]

Hello Tony,

Thanks a lot for your investigation! Now it's pretty clear
what naming schemas we can and cannot use.

Tony Theodore schrieb:
> On 21 March 2012 08:43, Tony Theodore <address@hidden> wrote:
> > On 21 March 2012 07:24, Volker Grabsch <address@hidden> wrote:
> >
> > binutils doesn't recognise mingw, so we may have to stick with mingw32.
> 
> Thankfully, this failed early. I get the impression that mingw32 is
> going to take a long time to change.
> 
> The VENDOR part, however, doesn't seem to be used at all.
> [...]
> All in all, I think we can re-purpose the VENDOR segment without any
> ill effects.

Okay, so all in all, the following naming scheme is be
the simplest one that will almost certainly work after
adjusting a few packages:

    (i686|x86_64|ppc)-(static|dynamic)-(mingw32|darwin9)

One minor detail, though:

> Three of those (qt, sdl, sdl_mixer) will fail even if you use the
> canonical:
> 
> make TARGET=i686-pc-mingw32
>
> since they have TARGET variables in various makefiles that relate to
> actual build targets, and the value specified at the command line
> overrides the makefiles.

What "make" call do you mean here? Is the our main Makefile,
or the Makefile of the respective library?

If it's our main Makefile, I find it somewhat strange that
the "TARGET=" argument makes such a difference. I would have
expected that only when the build rules were calling the
library Makefile via "make -e".

> We can get around this by simply prefixing
> the target variable (MCE_TARGET in this case) or simply not worrying
> about it since we're more likely to have a TARGETS (plural) variable
> in the future which won't conflict with makefiles. If you change
> TARGET in the main Makefile, they build without issue.

Although we'll have a TARGETS variable, for each individual
build there will still be a (temporary) TARGET variable.

So we'll have to find a solution to this. In the worst
case, we'll call the sub Makefiles with an empty target
like "make TARGET=" and/or perform some SED action on
the Makefile. But I'm sure we'll find a cleaner solution. :-)

In any case, it's pretty clear we'll be able to make
this work.


Regards,
Volker

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