Re: [Boost-build] Problems with alternatives

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-09-01 16:08:27

   Hi João.

> I do can compile, and the rules seem to be being followed. But I get
> the following error:
> 
> error: No best alternative for ./system_monitor_sources
>     next alternative: required properties: <host-os>windows <threading>multi
>         not matched
>     next alternative: required properties: <host-os>linux <threading>multi
>         not matched
>     next alternative: required properties: <host-os>unix <threading>multi
>         not matched
> ...found 21 targets...
> ...updating 6 targets...
> 
> Compilation goes on as if the rule for linux was in fact matched. The
> multithreading is set as a project requiremente in the Jamroot file of
> the whole project. Do you have an idea why it says that the linux rule
> is not matched?

   Hmmm... you'd have to post a minimal example so someone else can 
reproduce the issue. Can't really see what was going on when you got 
those messages.

   You might try running Boost Build with the --debug-building option to 
see what exact properties are getting used for each built target.

   If I were to guess, I'd say your system_monitor_sources target is an 
alias that you forgot to make explicit and Boost Build is attempting to 
build it 'by default' without some unexpected options. Just guessing 
here though...

> As for the second problem, again following your directions, I found
> that the problem is of other nature: since the lib is only suposed to
> be built on a specific OS, the sources list becomes empty in all
> others and triggers an error:
> 
> error: No best alternative for ./mylib_sources
>     next alternative: required properties: <host-os>windows <threading>multi
>         not matched
>     next alternative: required properties: <threading>multi
>         not matched
> /usr/share/boost-build/build/generators.jam:851: in try-one-generator-really
> *** argument error
> * rule object(gcc-linking-generator)@31.run ( project name ? :
> property-set : sources + )
> * called with: ( object(project-target)@110 mylib :
> object(property-set)@128 :  )
> * missing argument sources
> /usr/share/boost-build/tools/gcc.jam:428:see definition of rule 'run'
> being called
> 
> Is there any way to disable entirely the lib compilation on a specific platform?

   Well, there are several thing you can do or want to do here. You can 
use different alternatives, conditional properties with the source 
property or something else... depending on what you need or want to happen.

   First, you need to decide what you want to happen when you start bjam 
without specifying any target and then you need to decide what you want 
to happen when you explicitly specify the lib target as a dependency for 
some other built target or list it on the command-line.

   I'll assume you want to have the libs simply silently not be built on 
your OS-X if you do not request them explicitly and that you want 
building them to fail if they get requested explicitly. I'll also use 
the <toolset> feature instead of the <host-os> one as that was easier to 
test for me. In that case you could do something like this:

> rule allow-only-on-gcc ( properties * )
> {
>     if ! ( <toolset>gcc in $(properties) )
>     {
>         return <build>no ;
>     }
> }
> 
> lib b-lib : b.cpp : <toolset>gcc ;
> lib b-lib : : <conditional>@allow-only-on-gcc ;
> explicit b-lib ;
> 
> exe aaa : a.cpp : <toolset>gcc:<source>b-lib ;

   The problem with using the <build>no property is that you do not get 
any kind of a description of why a particular target refused to be 
built, the message you do get will most likely confuse a naive user and 
even the extra output you get using the --debug-building option will not 
help clear things up. Effectively - there is only a notification that 
there is a <build>no property specified for a specific target but no 
information on why this has been added.

   Another way would be to do something like this:

> import notfile ;
> 
> lib b-lib : b.cpp : <toolset>gcc ;
> notfile b-lib : @b-lib-fail-action ;
> explicit b-lib ;
> 
> actions b-lib-fail-action
> {
>     echo b-lib library can not be built with toolsets other than gcc.
>     exit -2
> }
> 
> exe aaa : a.cpp : <toolset>gcc:<source>b-lib ;

   Which would get you a bit better error message, even though it would 
be better if we could make it not display the failing command. A slight 
potential problem here is that you might have an OS where the 'exit' 
command does not do what we want which would need fixing then. Then 
you'd need to tweak the example a bit to issue different commands on 
different OS's.

   Things get a bit simpler if you decide you want explicitly requesting 
a library with an incorrect toolset to be simply silently ignored:

> lib b-lib : b.cpp : <toolset>gcc ;
> alias b-lib : ;
> explicit b-lib ;
> 
> exe aaa : a.cpp b-lib ;

   That should give you different techniques you can combine and use 
yourself. Possibly someone else can suggest some more.

   Choose whatever suits you best, and if some of them does not really 
suit you perfectly, post a suggestion for a different interface here. If 
possible, try to update Boost Build itself to do what you want it to do 
and post back a patch... the best thing about it is that it is open 
source. :-)

   Hope this helps.

   Best regards,
     Jurko Gospodnetić