Re: [jamboost] Need Help w/Prebuilt Targets and Include Path

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:

msvc.link.dll bin/msvc/debug/tools.so bin/msvc/debug/tools.lib 
bin/msvc/debug/tools.rsp

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

and 

gcc.link.dll bin/gcc-3.4/debug/tools.so

"g++-3.4" -L"/path/to/log4cplus/lib" -o "bin/gcc-3.4/debug/tools.so" 
-Wl,-h -Wl,tools.so -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,libported.so" and not
> "libported.so.1.0" 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 = [ os.name ] ;

> 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