From: Ulrich Eckhardt (gclbb-jamboost_at_[hidden])
Date: 2003-08-24 14:20:11
Rene Rivera wrote:
> [2003-08-24] Ulrich Eckhardt wrote:
>>Two things here: I wonder if the use of BOOST_ROOT is right here.
> 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
>>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
>>Therefore, and to give %USER% a bit more choice, I thought to do this:
>>SDL_CXXFLAGS ?= "`sdl-config --cflags`" ;
>> : # requirements
>>This also works, but still invokes the script every time the compiler is
> 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 :-(
>> 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 ;-)
> 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
> to your problem. It get evaluated twice because Boost.Build.V1 reads in
> 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
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
and not (even though it is the first one would do) this
(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
> template SDL : :
> # etc...
> : ;
> exe foo
> : # sources
> : ;
Thank you, that is a Good Technique(tm) !
One last thing: are there multiline-comments like /* */ in C/C++ ?
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