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 ;
>>>> 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
> Sure, but the likelihood of non-expert users doing that set up is
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
>>> 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 www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk