Re: [Boost-build] [Boost.Build V2] #70: Build all variants

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2006-06-17 14:11:29

Rene Rivera wrote:
> Vladimir Prus wrote:
> > On Saturday 17 June 2006 19:00, Rene Rivera wrote:
> >>> Of course, if you'd like to help with it, you're much welcome!
> >> If I knew how I would :-)
> > 
> > I think we need to this this multi-variant build only for Boost, and not by 
> > default by any means.
> 
> a) No. I personally use, or at least I did when I was using BBv1, the 
> multi-variant build functionality. And this is one of the long standing 
> Boost.Build trademark features. I.e. of building multiple variations 
> with one invocation.

It is even in the BBv2 tutorial :):

   "Now let us build both the debug and release variants of our project again:

      bjam debug release"

> b) Not sure what you mean. But if you mean not being able to request 
> multiple variants from the command line, then I disagree.

This can get complicated.

> > So the best solution would be either:
> [...]
> > The user interface could be something like that:
> > 
> >   build $(all-libraries) : debug release <threading>single <threading>multi ;
> 
> So basically it would not be possible to request multiple variants from 
> the CLI :-(

What's different in specifying what to build on the command line and as part of
the build script?

The problems with doing:

   bjam -a msvc-8.0 msvc-7.1 debug release threading=multi threading=single

are thus:

(1)  Having any install actions result in a duplicate generator error, e.g.

   install foo : bar ;

(2) BJam/BBv2 is correctly interpreting the toolset and variant features, and is
building 8 versions (toolset x variant x threading), but is passing threading=multi
to all of them; that is, threading isn't being properly propagated.

(3) Given an invalid combination, you don't want to grind the entire build to a halt:
you want to issue a warning that the combination is not possible and then move on.

(4) How do you interpret libraries that enforce build criteria (e.g. threading=multi)?
You should issue a warning and try to build as much as possible. I believe that
BBv2 supports this, just like if some targets fail to build.

> >> It means that the MinGW + STLport 5.x doesn't work on single-thread
> >> mode. It's just not supported by STLport. So the stlport.jam has logic
> >> in it to refuse to build the single-thread variants.
> > 
> > Do you refer the the logic in the 'match' method? I believe it was added by 
> > yourself in revision 1.18 of stlport.jam, so I really can't comment if it's 
> > right or wrong ;-)
> 
> Well, the original STLport match logic was by Reece and you AFAIK ;-) I 
> just changed it to include 5.x. But I refer to the no-match not 
> resulting in an error, but instead falling back to some other variant 
> which I didn't request when I invoke with "bjam --v2 toolset=mingg 
> stdlib=stlport-5.1"

I only reported a bug when having two versions of STLPort in user-config.jam,
so I have no idea what is going on there :).

> > What if we allow to specify non-free features (like <threading>multi), in 
> > usage requirements, and if the target specifies some values of such feature, 
> > but is built with another, produce an error?
> 
> I'm not sure I see the logic. Would it mean that the stlport pseudo 
> targets would have the <threading>multi?

If you have:

   lib wave : ... : : <threading>multi ;

then you would expect wave to be built as a multi-threaded library. If you then
have:

   exe compiler : ... wave ; # no threading specified

and build that with:

   bjam threading=single

you would expect wave to build (using threading=multi -- overriding the CLI,
unless there was also a:
   lib wave : ... : <threading>single ;
but we are assuming here that there isn't). However, when building compiler, it
should fail with a requirement conflict (requesting to be single threaded on the
CLI, and multi threaded from inhreiting the wave options). At the moment, I
think that BBv2 bails out with an error, whereas it should mark compiler as being
unbuildable and then continue.

A more interesting thing is having:

   lib test : ... : : <link>static ;
   exe foo : test/<link>shared ; # [1]
   exe bar : test ;

Here, [1] should produce an error when building foo (requirement conflict), but
should still build test and bar as these don't have conflicts. If you built this using:

   bjam link=shared

then nothing shall build as test cannot be built due to the requirement conflict.
BBv2 should not override the user here (I can't recall what it's behaviour is in
this regard).

> > I don't like the idea to automatically propagate non-free usage requirements, 
> > since you can suddenly get all your project building with <threading>multi 
> > without knowing there it comes from. With error, you can consider the 
> > situation and if MT looks like the right choice, change global requirements.
> 
> Well definitely propagation is bad :-) BBv1 produced a warning, which 
> could be programatically turned off, in this particular situation.

Mixing threading models is bad, so should be consistent. Given:

   lib wave : ... : : <threading>multi ;
   exe compiler : ... wave ; # no threading specified

I think it is a good idea to produce an error and then not build compiler, as
this indicates a potential probem (especially if compiler is written to behave
as an STA, but builds without errors with <threading>multi - very difficult
to track down as this may lead to random crashes at runtime).

> > Thoughts?
> 
> Ultimately I think we need to figure out how to support requesting 
> multiple variants generally. At minimum a syntax for specifying them in 
> the CLI. And preferably also specifying them in the default-build of 
> projects and targets. As is possible with BBv1.

This is possible to a certain degree: it is possible with toolset x variant.
The problem is when you start combining other features (like threading
or rtti) and have install rules that things start getting interesting :).

Unfortunately, I have limited knowledge of the inner workings of BBv2
to provide a solution at the moment.

- Reece
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/