Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-06-23 01:48:10


Mark Elston wrote:
> My last email may have been too vague.

Actually, I'm sorry I did not reply that email yesterday, but I was just too
busy hunting down bugs.

> I have two main questions. The first is how do I specify different
> sets of project settings (<cxxflags>/<linkflags>/etc) based on
> release/debug configuration and, also, based on Windows or Linux
> builds.

Ok, I'll add comments inside your Jamfiles.

> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> #
> # Project root Jamfile
> #
>
> # Should these go, instead, in the project-root.jam file?
> # Is there a preference? If not, what is that file really for?

These should to in top-level Jamfile. They simply won't work in
project-root.jam. To answer your question, the *primary* role of
project-root.jam in my opinion is to mark the root of the project, so that
Boost.Build does not try inherit properties from Jamfile in higher-level
directories.

For me, it does not make sense that some constructs are allowed in
project-root.jam (see below), but not in Jamfile. Probably, project-root.jam
should be just automatically included in top-level Jamfile...

> project
>
> : requirements
>
> <include>./inc
> # Other include directories
>
> # The following are Linux-specific settings.
> # I need to add settings for Windows-specific
> # compilation and linking as well that will be common
> # to all sub-projects. I also need to specify a
> # different set based on Release/Debug/Purify configurations.
> <cxxflags>-w <cxxflags>-fpic
> <linkflags>-fpic

You should use conditional properties:

<variant>release:<cxxflags>-optimize
<variant>debug:<cxxflags>-pessimize

This works for platforms, too.

<os>LINUX:<cxxflags>-linux

> # This is the current project I am working on right now.
> # However, there are *many* projects with many dependencies.
> # Do I have to specify them all here? Is there another way?
> # I would like to still be able to specify a single project
> # to build from the command-line either at the top level or,
> # more likely, at the project directory level.
>
> build-project src/OAI/utils ;

This depends on what you want. If you want all your projects to be built if
you run bjam in top-level directory, then yes, you have to write several
"build-project" lines. If you don't want to build them all, you don't need
the lines.

In either case, you'll be able to build a single project by running somehting
like

bjam libs/lib1

> # I have tried putting this in the top-level Jamfile but it
> # doesn't seem to matter much. My project-level Jamfiles don't
> # seem to be able to pick it up. Why not?
> EXT = ;

Because each Jamfile is a separate module with separate namespace.
You can achieve the effect you want with

constant EXT : foo ;

in project-root.jam. After this, EXT, will be available to all projects.

> if debug # or if <variant> = debug , or ...
> {
> EXT = _D ;
> }
>
> # This is used below in trying to get a different extension
> # on the resulting libs and exes based on the type of build
> # being performed (release/debug/etc).

Actually, since you can build both release and debug variants in a single bjam
invocation, it's hard to write proper "if". However, you can try this:

project
: requirements <variant>debug:<tag>_D
;

this will add _D to all targets when variant is debug. You might not want to
do this for all targets, only for exes and libs. One solution might be to put
this into project-root.jam:

rule my_exe ( name : sources * : requirements * : default-build * :
usage-requirements * )
{
requirements += <variant>debug:<tag>_D ;
exe $(name) : $(sources) : $(requirements) .....
}

And then use "my_exe" in your project.

HTH,
Volodya

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk