Boost logo

Boost-Build :

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.


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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at