Re: [Boost-build] Usage of host-os and target-os for toolset gcc ?

From: David Abrahams (dave_at_[hidden])
Date: 2007-03-19 12:54:59

on Fri Feb 23 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

> To summarize my overall POV in case it gets lost in my responses 
> below... host-os, target-os, and flavor are all independent variables in 
> describing a compiler's behavior. Hopefully host-os and target-os are 
> self explanatory, which leaves flavor. Since I came up with it here's 
> what I mean it to be:
>
> "flavor"
>      A variation of the particular compiler for a particular host-os and 
> target-os combination. This can apply to compilers that are either: 
> frontends emulating a single compiler and dispatching to backend 
> compilers, or different versions of the same compiler that behave 
> differently irrespective of all other factors.

I agree with that perspective.

> Roland Schwarz wrote:
>> The current handling of the gcc in Boost.Build currently looks
>> troublesome to me. I try to restate the problems I see and hopefully
>> lead to a discussion of how these problems can be overcome.
>> 
>> 1) various flavors of gcc:
>> 
>>     gcc can be configured as a cross compiler, although I don't think
>>     this strictly relates to "flavor".
>
> I think cross-compiling is a host-os/target-os matter.

Agreed.

>> On windows gcc can be obtained
>>     as a
>> 
>>     *) "mingw" excutable, where the compiler itself depends on
>>        msvcrt.dll. This mingw flavor also is able only to produce
>>     target code, that depends on msvcrt.dll. Gcc as
>> 
>>     *) "cygwin" executable, where the compiler itself depends on
>>        cygwin1.dll, can produce target code that either depends on
>>     cygwin1.dll (the default) or msvcrt.dll (using switch -mmo-cygwin).
>
> AFAIK what the -mno-cygwin switch does is tell the frontend to call the 
> mingw executables, which are part of the cygwin distribution, to do the 
> compiles and links.

If that's what you mean by "flavor," I dig it.  I was under the
impression that "flavor" was being used to select cygwin or windows
targets for generation by gcc, which is properly the role of
target-os.

>>     The cygwin exe can be invoked from either the cygwin bash or from
>>     CMD.EXE. When invoked from CMD.EXE one must make sure that the
>>     cygwin1.dll and other helper dlls can be found, e.g. by putting
>>     them into PATH environment variable.
>>     Since gcc is available on a lot of platforms it is not obvious if
>> 
>>     *) "native" executable should be the flavor on these platforms,

IMO "flavor" should not be used to describe the type of executable
generated.  That's a target-os issue.

>>        I'd rather guess a more specific name like linux, or similar
>>     being more appropriate.
>
> Perhaps... We decided not to add a flavor unless needed because when a 
> flavor is specified it ends up in the toolset name. This caused, since I 
> initially added the flavor for all GCC version, the regression markup to 
> become invalid and to general confusion when the toolset specified did 
> not match the user visible toolset name (you mention part of this below 
> also). But if we want to go back to having the flavor specified we would 
> need to be careful in choosing labels to stay away from 
> host-os/target-os terms. So "linux" is right out, "posix" might be an 
> alternative.

Grrr.

>> 4) Problems with the flavor approach:
>>     If you request an incomplete specification from the bjam cmdline:
>>     e.g.: bjam gcc-3.4.4, with having configured two toolset's:
>> 
>>     using gcc : 3.4.2 ;
>>     using gcc : 3.4.4 ;
>> 
>>     you always will get the flavor of the first configured compiler,
>>     which is plain wrong. In this case the flavor of 3.4.2, which
>>     might be different than 3.4.4.
>> 
>>     The request bjam gcc-3.4.4-mingw in contrast is complete and will
>>     work correctly. (Note again: bjam toolset=gcc-3.4.4-mingw does
>>     currently not work either.)
>
> That's not a problem, that's a *bug*.

Can we fix it?  I am running into a similar problem with Python
configuration, although I'm not quite as convinced it's a bug.  We may
be missing a feature required to express what we want to do.

>> 5) host-os and target-os features.
>>     As already has been suggested by Dave in another post, I too think
>>     using these features in the context of cygwin/mingw will be
>>     beneficial. My thoughts about this approach:
>> 
>>     *) host-os and target-os must be somehow set by default, similar
>>        as "debug" is getting set by default. So if a user does not
>>     mention them explicitely they nevertheless get into the build
>>     request.
>
> They already do. Both have, as the always set default, the running
> OS. 

Except the code to set that was broken.  I fixed it recently in the RC
branch (but not in HEAD).

> The detection of what the running OS is might need improvement
> though.  Although host-os is optional at the moment, to prevent it
> from showing up in the build path.
>
>>     *) While host-os and target-os can describe what the target
>>        requirements are, I can see no way how to find out if a
>>     given compiler will be able to perform the requested operation,
>
> I think that's a general problem of build systems. Short of carefully 
> interrogating the compiler, or pre-testing the capabilities (ala 
> autoconf) we have to rely on users assertions about the tools available. 
> Of course I note that this is easier for some compilers, notably msvc, 
> as they have well defined capabilities.
>
>>     by considering these two properties alone:
>>     E.g. host-os=windows target-os=cygwin . The "cygwin" executable
>>     can do this while the "mingw" executable is not capable of producing
>>     the requested target. Consequently there must be something that
>>     identifies the compiler. E.g. a "flavor".
>
> It is possible to build a mingw cross-compiler that would allow 
> production of such a combination. But this would still be a mingw 
> flavor. This leads to credence to using only host-os/target-os, and 
> making cygwin an OS variant. But this still doesn't account for the 
> possibility of having many other GCC compilers that can produce the 
> windows->windows combination, the windows->cygwin, or the 
> cygwin->windows combination.

Right, e.g. conceptgcc, just for one.

>>     *) The host-os and target-os I suspect need to be present in the
>>        physical path names of the file targets. This will make the
>>     pending path length problem even worse.
>
> I posted a variety of proposals on how to remedy the path length problem 
> over the past year. I think the last one has the most potential.

We do have --abbreviate-paths, FWIW.

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