Re: [jamboost] BBv1: adding libraries to target

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-08-24 12:35:32

[2003-08-24] Ulrich Eckhardt wrote:

>Greetings!
>
>I'm trying to build an existing project which uses a few other libs. To
>some extent it works, but I'm not confident that the result and the way to
>it are good.
>
>I'm using three external lib: boost_thread, SDL and SDL_net. They all
>require different steps to compile and link. For the sake of simplicity I
>have split these up in this post, I hope that doesn't change anything.

OK.

>1. boost_thread: for this one, I have only yet found a solution for
>compiling, for linking I still have to select the proper version by hand
>and add that to the linkflags:
>
>exe foo
> : # sources
> foo.cpp
> : # requirements 
> <include>$(BOOST_ROOT)
> <find-library>boost_thread
> # (added linebreaks for readability)
> <linkflags>-L../boost-1.30.2/libs/thread/build/bin/
> libboost_thread.so/gcc-3.2/debug/runtime-link-dynamic/
> shared-linkable-true/threading-multi/
> ;
>
>Two things here: I wonder if the use of BOOST_ROOT is right here. That
>variable is used by the build-system to find its components but not
>necessarily to find the boost-sources. Imagine, in theory, you could use
>the build-system of one boost to compile and link a program that uses a
>different version. (Yes, I know that this is very philosophical and it
>also doesn't really concern me ATM).

Yes, you should worry. BOOST_ROOT is set in boost-root/Jamrules, and
therefore will only be set when building from within Boost itself.

In my project I do something like so (in my Jamrules file):

CVSROOT = [ root-paths $(PROJECT_ROOT)/../../../../.. : [ PWD ] ] ;
BOOST = $(CVSROOT)/org/boost/Boost ;

And I set the PROJECT_ROOT in my boost-build.jam:

PROJECT_ROOT = [ find-to-root [ PWD ] : $(JAMRULES) ] ;
PROJECT_ROOT = $(PROJECT_ROOT:D) ;

And then I use <sysinclude>$(BOOST) in my targets.

>The second thing is the 'hard-coded' path to the library. This will break
>for other users, or even for me should I decide to change from debug to
>release. Using separate '<debug><linkflags>-L...' and
>'<release><linkflags>-L...' is not really an alternative. 
>
>What I would like to do in that case is to tell the buildsystem "you find a
>Jamfile for the boost_thread lib/dll at $(BOOST_ROOT)/libs/thread/, link
>this executable with the right version of it".

Only BBv2 has the facility to do what you really want :-)

I find it much easier to just recreate the boost_thread targets in my own
project. Just copy, and modify accordingly, the contents of
boost-root/libs/thread/build/Jamfile to your project. 

>2. SDL: SDL generates a script at install-time that can be called with
>different arguments to get the right flags for compiling other programs
>with it.
>
>The first (and working) approach was to use it directly:
> ...
> : # requirements
> <cxxflags>"`sdl-config --cflags`"
> <linkflags>"`sdl-config --libs`"
>But this approach calls the script at every invokation of the compiler,
>which is unnecessary. Also I'm not sure about the portability of using
>backticks (`) outside of bash.

Backticks should work in most shells, but won't work in Windows ;-) I
imagine you'll eventually want to target something other than Unix, et all.
[side note, I hate the growing trend to use such *config programs, PITA they
are, and they hide things I really want to see]

>Therefore, and to give %USER% a bit more choice, I thought to do this:
>
>SDL_CXXFLAGS ?= "`sdl-config --cflags`" ;
> ...
> : # requirements
> <cxxflags>$(SDL_CXXFLAGS)
>
>This also works, but still invokes the script every time the compiler is
>invoked. 

This one is identical to the first one, the variable is expanded to the same
options. But it does let the user override the value at least :-) [I do have
suggestions on this... just see below]

Sadly running such config commands for each call to compile is exactly what
the creators of those commands intend and suggest you do :-(

>Therefore:
>
>rule sdl-config-cflags
>{
> ECHO "inside rule sdl-config-cflags" ;
> return [ Run sdl-config --cflags ] ;
>}
>SDL_CXXFLAGS ?= [ sdl-config-cflags ] ;
>
>However, there I probably have a problem understanding the way jam or boost
>build works, because I do see that the rule is called (or should I say
>invoked ?), it even prints the echo twice (I wonder why) but the 'Run ...'
>is not evaluated. It even seems that the Run-call gets totally ignored,
>even if I call it with a program that doesn't exist or one that starts a
>GUI nothing changes !?

"Run" is an action used internally, so I would recomend using it ;-) Because
it's an action it will only "run" it's actions when executing the build
actions, which happens last in the build process. Hence one reason why it
has no seeming effect here, there are othre reasons but they are tangential
to your problem. It get evaluated twice because Boost.Build.V1 reads in all
Jamfiles twice. It's done that way to solve the unordered definition/use
aspect of targets in BB.

My suggestion is to not use the sdl-config script at all, and recreate it's
functionality in BB. Those scripts tend to be very simple, and BB can
usually do what they do in better ways. And taking a look at the SDL1.2
sdl-config script... it is indeed very simple. I'd say run it, look at it's
output and create a "template" for what it does possibly like:

template SDL : :
<sysinclude>/usr/local/SDL-1.2/include
# etc...
: ;

exe foo
: # sources
<template>SDL
foo.cpp
: ;

>3. SDL_net: this one should only require the compile-flags of SDL (is there
>a sensible way to define that dependency here?) and the additional lib
>called SDL_net which I added to the requirements using 
> <find-library>SDL_net
>This works, I just wonder if that is The Right Way(tm).

If you use the above template approach you can add another template for
SDL_net use:

template SDL_net : <template>SDL :
<find-library>SDL_net
: ;

And, yes, find-library is the way to do it.

>Lastly, I wonder if there is a FAQ or something like that. I can't imagine
>my problems are so special that they werent solved already.

No official FAQ, nor unofficially ;-) But adding to the Boost.Wiki would be
the place to do it... If people want to contribute, that is.

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq