Re: [Boost-build] Wacky handling of MinGW

From: David Abrahams (dave_at_[hidden])
Date: 2006-12-12 00:12:00

Rene Rivera <grafikrobot_at_[hidden]> writes:

> 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, 

I understand that mingw follows a pattern seen elsewhere.

> as that's why the code exists in the first 
> place. 

*What's* why *what* code exists?

> 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 :-)

I just don't understand why that distinction can't come from the
version name that the user assigns to the toolset.  All the other gcc
versions that get configured are distinguished that way.  Why do we
need special treatment for a mingw toolset?

>>> 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 :-\

I think the appropriate response at this point is "whatever" :)

>>> 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.

Huh?  We have other features that affect name mangling.  Anyway,
"global" (module scope) variables and toolset configuration go
hand-in-hand.  Where do you think all that information gets stored,
anyway?

>> 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. 

What's wrong with

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

?

That's uniform.

> 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 ;
>

Well, this one you would handle by switching on the host os, since we
don't yet do cross-compilation, but ignoring that argument for the
moment:

    using como : 1.0.0_linux : /path/to/linux/g++ ;
    using como : 1.0.0_win : /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 ;-)

Hmm... "whatever?"

>> 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.

Somebody will have to help me understand what problem we're solving by
putting it in the toolset name before I can suggest anything.

>>> 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.

Thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com