Re: BBv1: adding libraries to target

From: Ulrich Eckhardt (gclbb-jamboost_at_[hidden])
Date: 2003-08-24 14:20:11

Rene Rivera wrote:
> [2003-08-24] Ulrich Eckhardt wrote:
>> <include>$(BOOST_ROOT)
>>Two things here: I wonder if the use of BOOST_ROOT is right here.
[snip]
> Yes, you should worry. BOOST_ROOT is set in boost-root/Jamrules, and
> therefore will only be set when building from within Boost itself.

Hmmm, I work from outside the boost-rootdir and I set BOOST_ROOT in the
environment. However, IIRC, I didn't start doing so in order to use the
path but because the build-system bailed out if I didn't...

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

I just exchanged <include> with <sysinclude>, it didn't change anything in
the compile-command. Is that dependent on the particular
platform/compiler? Is <sysinclude> for '#include <>' while <include> is
for '#include ""' ?

>>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.

>>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:

That doesn't work. The script is created at install-time and therefore
knows the locations where the particular user installed their version.
Also, according to SDL's instructions, you are supposed to do this
#include "SDL.h"
and not (even though it is the first one would do) this
#include <SDL/SDL.h>
(Yes, I hate it too.)

Anyways, is there no way to put the result of running on external program
into a variable ? How does dependency-tracking work if not by running the
compiler on a file ?

> [side note, I hate the growing trend to use such *config programs, PITA 
> they are, and they hide things I really want to see]

What is your problem with those ? They finally seem to become even
standardized a bit with pkg-config. However, that is drifting a bit off
topic here.

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

Thank you, that is a Good Technique(tm) !

One last thing: are there multiline-comments like /* */ in C/C++ ?

thank you
Ulrich Eckhardt