Re: [Boost-build] Wacky handling of MinGW

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-12-11 08:59:28

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

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

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

>>> Since I do see gcc-mingw-3.4.2 in my target paths, I thought I'd try
>>>
>>>       bjam gcc-mingw
>>>
>>> which again breaks in a strange way.
>>>
>>> What all of this does and how to use it needs to be explained and
>>> documented by someone who understands it.
>> That would be me... But I must confess, I just dread having to edit
>> the BBv2 BoostBook documentation files. I have no clue where to put
>> things and writing docs in XML is among the most painful tasks I can
>> think of.
> 
> Well, I feel sorry for you I guess.  Someone should make a
> BoostBook -> QuickBook translator for this purpose.

I made a BoostBook generated HTML -> QuickBook stylesheet that did 90% 
of the translation once upon a time :-)

>  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. I guess I could shove the docs into the gcc.jam, but I'm 
guessing you wont be happy with that ;-)

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