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

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-02-25 05:50:44

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

Thank you for clarification! This is exactly how I understood, it was 
meant to be. Just it does not work like so. :-(

> Perhaps... We decided not to add a flavor unless needed because when a 
> flavor is specified it ends up in the toolset name. 

I think it is a good thing when the flavor can be seen 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). 

The regression mark up was hampered even so. This fact just didn't raise
it's head until I started to run the regressions for gcc on windows.

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

I do understand ( and second ) this. The flavor names (as derived from
g++ --version) could be: "mingw" "cygming" on windows. Perhaps
"native" would be a sensible name for linux?

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

Unfortunately it is not obvious how to solve it, or even if it can be
solved. I am afraid it interferes severely with the auto-configuration
code. Al though it would be easy enough to strip off only the version
part from what the user supplies on the commmand line, it is unclear
what should happen when the user specifies:

bjam toolset=gcc-3.4.4-mingw

on the command line:

   *) auto-config splits into gcc and 3.4.4
   *) if this version is already configured
      everything works well
   *) if this version is not yet configured we have a problem:
      toolset.using $(toolset) : $(version) ; # line 194 build-syste.jam
      will not pass on the "mingw" part. Since the auto-config
      is not (and shoud not be) specific to gcc it is unclear how
      to pass on this information.
      Perhaps the author of the  auto-configuration has an idea how
      to solve this?

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

Can you give me please a little example, how I could notice that the
feature indeed is present. I was not able to see any effects, besides
being defined in the sources.

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

I think this is where user-config.jam and site-config-jam where meant
to drop in. Perhaps it would be a logical extension to extend the
toolset.using with a toolset.autoconfig part which is given the
toolset= from the command line as a parameter. In this way auto config
could be made toolset specific.

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

Would you mind, giving me a short pointer to your last proposal?

> This is certainly a solvable problem... It just takes putting in the 
> appropriate info into the XML results and having the markup allow use of 
> more info in the XML results.

I understand.

Thank you,
Roland