Re: [Boost-build] Wacky handling of MinGW

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-12-11 22:06:51

David Abrahams wrote:
> Rene Rivera <grafikrobot_at_[hidden]> writes:
>> David Abrahams wrote:
>>> Rene Rivera <grafikrobot_at_[hidden]> writes:
>>>> David Abrahams wrote:

>>>> That would be the "flavor" feature being injected to distinguish the 
>>>> MinGW specific GCC version.
>>> I don't understand why that needs to be injected by the system into
>>> the toolset name.  There's no reason I couldn't
>>>
>>>     using gcc : 3.4.2-mingw : /tools/MinGW/bin/g++.exe ;
>>>
>>> if I needed the version to be distinct from other GCC versions I have
>>> installed.

Just an FYI... Currently the code is equivalent to specifying:

   using gcc-mingw : 3.4.2 : /tools/MimnGW/bin/g++.exe ;

But of course there's no "gcc-mingw.jam" file so it wouldn't work. The 
extra subfeature of the toolset is added by existing code, i.e. Volodya 
wrote it. I just used it the same way that the intel-win/linux and 
como-win/linux uses it, as that's why the code exists in the first 
place. What I did was the equivalent of what the intel and como toolsets 
do but in an automated way. Which essentially means that the "mingw" is 
needed in the toolset name in order to distinguish it from other gcc 
compilers on the same machine, aka the cygwin version :-)

>> Sure, but the likelihood of non-expert users doing that set up is
>> small. 
> 
> Yeah, but the likelihood of non-expert users needing a gcc-3.4.2-mingw
> and a gcc-3.4.2-cygwin is even smaller.

I'm not so sure about that. I would expect many users having both cygwin 
and mingw. The former to compile those "standard" Unix like programs. 
The latter to work on native applications. There's no easy way to know 
though :-\

>> The MinGW distinction is needed to comply with the name mangling. That 
>> is so that we can produce the built results with "mgw" in the names.
> 
> I don't see why that needs to creep into the toolset name.

Because AFAIK there's no other way to add the appropriate information to 
the build variant such that the name mangling rule can get at it without 
using global variables.

>>>>> What would I do if I also had a cygwin gcc-3.4.2 installed?  I don't
>>>>> know.
>>>> Just treat it as a regular Unix gcc:
>>>>
>>>>    using gcc : : /path/to/g++
>>>>
>>>> And build with:
>>>>
>>>>    bjam gcc
>>> Yeah, but it's not my default gcc; I need a version identifier
>>> (number?).  What do I use for the 2nd argument?
>> It autoconfigures the version number, so it's optional.
> 
> I know it autoconfigures the version number.  My point is:
> 
>   using gcc : 3.4.2 : /tools/MinGW/bin/g++.exe ;
>   using gcc : 3.4.2 : /usr/local/gcc-3.4.2/bin/g++.exe ;
> 
> is at best confusing and at worst ambiguous to the system.

Well the best I can suggest is that we make the first line above a 
configuration error and force users to specify it as:

   using gcc-mingw : 3.4.2 : /tools/MinGW/bin/g++.exe ;
   using gcc : 3.4.2 : /usr/local/gcc-3.4.2/bin/g++.exe ;

After making that possible of course. My concern is that the same 
problem applies to the handling of the como and intel toolsets where:

   using como : 1.0.0 : /path/to/linux/g++ ;
   using como : 1.0.0 : /path/to/windows/g++.exe ;

I know you'll bring up the assertion that one would never have that 
combination as it would be trying to run compilers from different 
platforms on the same machine. But with emulation anything is possible ;-)

>>>> If you also had the MinGW version set up you could:
>>>>
>>>>    bjam toolset=gcc,gcc-mingw
>>> Oh, nonono.  gcc-mingw does *not* work as a user-specified toolset
>>> name, at least not with toolset=..., perhaps because of the way
>>> autoconfiguration based on toolset= works: it parses the names with
>>> ([^-]+)(-(.*))? to get a toolset and version and uses the first two
>>> groups to call init if the toolset/version isn't known.  I am afraid
>>> this nonuniformity for MinGW is going to be *big* trouble.
>> Perhaps, but it's not limited to gcc-mingw. We've had for a long time 
>> now, intel-win, intel-linux, como-linux, and como-win toolsets. So I'm 
>> afraid it's "nonuniformity" the autoconf has to deal with. 
> 
> Again, I don't see why this junk has to appear in the toolset name.

Well I guess someone will have to come up with a suggestion as to how 
not to have that in the toolset name. And since I don't know how that 
only leaves Volodya and you.

>> OK, but where? AFAIK we don't document the individual toolsets in the 
>> BBv2 docs. 
> 
> We probably should.

So much documentation, so little time :-(

>> I guess I could shove the docs into the gcc.jam, but I'm 
>> guessing you wont be happy with that ;-)
> 
> It's better than nothing.  The existing comments need a rewrite
> anyway; they're mostly unintelligible or highly ambiguous it seems.

I'll see if I can clean some of that up then.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo