Boost logo

Boost-Build :

Subject: Re: [Boost-build] possible bug when cross compiling linux->windows
From: Moritz Hassert (mhassert_at_[hidden])
Date: 2010-09-21 13:03:31


I know I'm digging up something old here but only now I found the time to
investigate some more.

My current understanding:
Steve is right, we can't just make all subfeatures optional. In fact I think
it's the oposite: they all have to be non-optional, that is have to have a
default value.
The whole toolset configuration and usage depends on the fact that the first
time a toolset is configured, all subfeatures of that toolset get defaulted to
values that match that specific variant of the toolset. So if nothing is
explicitly requested on the command line, this first configuration variant will
be used.

If the version subfeature were optional, then putting the line
using gcc ; in /etc/site-config.jam
and doing
"bjam toolset=gcc"
would not work. One would always have to say
"bjam toolset=gcc toolset-gcc:version=4.4.3"
because toolset-gcc:version has no default value but the configured gcc has
that version as a condition.

If the flavor subfeature is made optional, everything is fine on linux. Native
configurations of gcc don't have that subfeature at all and therefore don't
depend on it being set on the command line. For mingw cross compilers one has
to explicitly add toolset-gcc:flavor=mingw. This is acceptable, because in this
case the user is requesting something special, non-default, and therefore has
to specify that. It's the only way to distinguish between a native gcc of the
same version and the crosscompiler.

But on Windows with the flavor subfeature being optional and no default value
assigned, one has to always add "toolset-gcc:flavor=mingw" to the command line.
This is a thing you don't want to do when you're not cross compiling.

My current solution is to also assign a flavor on Linux.
In gcc.jam I added a single line:
         switch $(machine:L)
             case *mingw* : flavor ?= mingw ;
+ case *linux* : flavor ?= linux ;

This works for me (although the build paths get even longer) but it just
doesn't feel perfect :)

I'd like to get rid of the <flavor> completely and instead use <target-os> as
the way to distinguish native from cross builds. Has anyone already done
something along these lines?


Steven Watanabe wrote:
> Moritz Hassert wrote:
> > Steven Watanabe wrote:
> >> Yep. I've hacked my working copy to allow mixing of
> >> mingw and cygwin. This doesn't work perfectly as
> >> I also had to put
> >>
> >> using gcc : 4.4.1 : "C:/MinGW/bin/g++" ;
> >> toolset.add-requirements
> >> <toolset-gcc:version>4.4.1:<toolset-gcc:flavor>mingw ;
> >>
> >> in user-config.jam
> >
> > I've tried your patch but it doesn't work for me:
> > 'error: "flavor" already declared as a subfeature of "<toolset>" specific
> > to gcc'
> >
> > This seems correct, as common.jam doesn't know about the predefined
> > subfeature and tries to define it again. Have you also patched your
> > common.jam?
> As a matter of fact, yes I have. Sorry. It's been a while
> since I looked at this. The changes I made to common.jam
> are attached.
> > I still think common.jam is the right place to add the 'optional'.
> I'm not certain that all features created this way should be optional.
> I was trying to avoid changing anything except <flavor>.
> > But as I wrote in my last mail, this results in empty build-commands and
> > - as I just notices - in a 'bin/gcc/debug/...' build dir. (Note the
> > missing version that is normally added, even when the default gcc is
> > used.)
> >
> > I guess the code that processes the subfeatures of toolset gcc doesn't
> > handle correctly subfeatures without default values. This looks like the
> > actual bug to me. But I 'm not familiar enough with boost build
> > internals to know where to start digging.
> In Christ,
> Steven Watanabe

AB+M GmbH 
Haid-und-Neu-Straße 7
76131 Karlsruhe
Telefon: (0721) 66488-0
Telefax: (0721) 66488-18
Geschaeftsfuehrer: Dipl.-Inform. Christopher Asp
Amtsgericht Mannheim HRB 105845

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