Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-03-22 06:54:02

On Wednesday 16 March 2005 21:40, Joao Abecasis wrote:

> >>I was trying to avoid generating quickbook multiple times if multiple
> >>toolsets were provided on the command line... but now I see boostbook
> >>itself already generates lots of errors in this scenario, so I can just
> >>forget about it.
> >
> > Do you mean that if quickbook worked for all compilers and for all
> settings,
> > you would retain the current behaviour of quickbook.jam?
> Actually I was considering the possibility of having docs built
> alongside the rest of a library. Quickbook itselft *should* already work
> with different compilers/settings...
> Consider library foo that has some exe targets alongside quickbook or
> boostbook docs. The corresponding Jamfile might read:
> exe foo_exe : foo.cpp ;
> boostbook foo_docs : foo.qbk ;
> Now, I want to build foo with multiple toolsets/configurations so I try:
> bjam (--v2) gcc intel release debug
> What I get is that boostbook blows trying to generate duplicate targets:
> error: Duplicate name of actual target: <phtml>HTML.manifest
> Ideally docs would be "toolset-agnostic".

Right. This is on my todo.

> Still quickbook is in a
> peculiar position because its executable certainly isn't compiler-agnostic.
> What I would like to happen here would be for the quickbook executable
> to be built once with a "default" toolset (from the above command-line
> I'd expect it to be gcc-release).

The only way to accomplish that is make the quickbook generator remember if it
was already invoked. It it was, it can return the same targets as it returned
the last time.

> >>... patience ...
> >>... deleting some lines from the quickbook toolset ...
> >>
> >>Done! More power to the user!
> >
> > I still think that generally building a tool once with default toolset
> > is good. However in the specific case of quickbook I just trust your
> judgement.
> My decision was not tied to quickbook knowledge. I also think the
> default toolset is a good idea. I just think it seems natural to
> override the "default" from the command line.

Maybe we have different ideas of "default". What I mean is that I have an
extra cool tool which takes image file and converts it into a C++ file (just
an example), I want to build it with gcc/debug, and don't want it to be
rebuilt when I type

bjam gcc-4.0

> Btw, how can I define a default toolset and mode (release/debug) other
> than changing the order in which toolsets are declared?

bjam --help feature.set-default

It's a bit risky to use it anywhere but in user-config.jam, though, because
what if two Jamfiles try to set it to different values?

- Volodya


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