Re: [Boost-build] Wacky handling of MinGW

From: David Abrahams (dave_at_[hidden])
Date: 2006-12-11 10:26:10

Rene Rivera <grafikrobot_at_[hidden]> writes:

> David Abrahams wrote:
>> Rene Rivera <grafikrobot_at_[hidden]> writes:
>> 
>>> David Abrahams wrote:
>>>> Eventually, with no assistance from documentation, I figured out that
>>>> I couldn't call my toolset gcc-mingw.  So I renamed it:
>>>>
>>>>      using gcc : 3.4.2 : /tools/MinGW/bin/g++.exe ;
>>>>
>>>> Now 
>>>>
>>>>     bjam gcc-3.4.2
>>>>
>>>> works as expected except that I see gcc-mingw-3.4.2 in target paths.
>>> 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.
>
> 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.

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

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

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

> I also note 
> that we currently have three different files for each of the intel and 
> como, which could be coalesced into single comprehensive toolsets using 
> the flavor feature. So there are benefits to having such handling around.

Sure...

>>  But all that
>> said, MinGW handling has to be rationalized and made clear.
>
> OK, but where? AFAIK we don't document the individual toolsets in the 
> BBv2 docs. 

We probably should.

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

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