Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-09 11:25:22

On Thursday 09 December 2004 18:04, Caleb Epstein wrote:
> OK, thanks. It works (mostly) now. I must have mistyped something in
> my Jamfile before but now the include paths are being picked up
> properly.
> I have a handful of additional questions now that I'm up and running,
> if this is the correct forum. Here goes:
> 1. I am now building my library from four separate targets, one of
> which introduces the log4cplus dependency. When this lib is being
> built, the compiler is being invoked with "-llog4cplus" but no -L
> flags to find it. I have this as my log4cplus target:
> lib log4cplus
> : <search>/home/eqdev/tools/linux-i686-gcc/log4cplus-1.0/lib
> :
> : <include>/home/eqdev/tools/linux-i686-gcc/log4cplus-1.0/include
> ;
> The <include> part seems to be working fine, and I would expect
> <search> to be the linker analog to <include> (e.g. setting -L instead
> of -I) but thats not happening:

Given Jamroot of:

lib tools : [ glob src/*.cpp ] log4cplus # tibrvcpp
: <include>include ;

lib log4cplus : : <search>/path/to/log4cplus/lib : :
<include>/path/to/log4cplus/include ;

I get: bin/msvc/debug/ bin/msvc/debug/tools.lib

/NOLOGO /DEBUG /subsystem:console /DLL /out:"bin/msvc/debug/" /INCREMENTAL:NO /IMPLIB:"bin/msvc/debug/tools.lib" /LIBPATH:"/path/to/log4cplus/lib"

and bin/gcc-3.4/debug/

"g++-3.4" -L"/path/to/log4cplus/lib" -o "bin/gcc-3.4/debug/"
-Wl,-h -Wl, -shared "bin/gcc-3.4/debug/a.o" -llog4cplus -g

So you have a testcase.

> 2. The current BBV2 doesn't seem to support versioned shared libraries
> correctly. Taking a cue from example/versioned/jamfile.jam, I have:
> lib libported : [ glob ported/src/*.cpp ] : <version>1.0 ;
> But the linker is invoked with "-Wl,-h -Wl," and not
> "" which I would expect.

That example is out of date, I'm afraid. Try

stage dist : libported : <so-version>1.0 ;

In a recent email, I've asking options on whether <so-version> should be used
on 'lib' targets. I'd appreciate if you read that email and comment. The
subject is "RFC: naming, dll versions and installing".

> 3. The FAQ discusses an indirect method of collecting program output
> for setting properties. I'd like to be able to run an external
> command to set variables in a Jamfile however. Specifically, I'd
> really like build-dir to contain some indication of what platform the
> build is for, so I can build using gcc on SunOS and Linux in the same
> tree without them stomping on each other. Is there some simple way to
> do this (e.g. an existing variable I can use without needing to run
> 'uname').

You can use

import os ;
local OS = [ ] ;

> If not, is the moral equivalent of GNU make's $(shell) ever
> likely to be added to Boost.Build?

We'd like to have it, but nobody is willing to write the code ;-)

- Volodya


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