Re: [jamboost] Re: BBv1: adding libraries to target

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-08-24 18:02:45

[2003-08-24] Ulrich Eckhardt wrote:

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

You should be able to set the BOOST_BUILD_PATH only. Or call the
"boost-build /some/path" rule from your boost-build.jam file (if any). The
BOOST_ROOT variable is there for backward compatability.

>> 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 ""' ?

Yes, it depends on the compiler. Some compilers use a different search
order, and have different options for specifying those.

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

Hmm, didn't know they changed that. Or maybe I just ignored their suggestion
last time I used SDL (in the 1.0 days ;-)

>Anyways, is there no way to put the result of running on external program
>into a variable ? 

Not currently. It's a long standing todo, to add a Jam command to do that.

>How does dependency-tracking work if not by running the
>compiler on a file ?

It doesn't run the compiler, as most compilers don't have any support for
generating dependencies. And when they have they only generate them in the
Makefile "prefered" format.

Boost.Build has source and header scanning built in. So it scans the sources
you give it, and its headers, etc. and uses the timestamps to figure out the
changed dependencies.

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

Not totally off-topic for the list, after all it's still a build issue ;-)

The basic problem is that they make Configuration Management a pain.
Specifically it hides a bunch of information about what I need to build
something in very inconvinient scripts whose contents are entirely up to the
individual machine install and not on the managers hands. Hence it makes
configuration of development installations a nightmare.

Which goes back to your attempts to use the script. For me when I need to
use an outside library the first thing I do is create a standard
fetch+build+install script. I put the libraries complete source into my
version control server (the script does it, plus branching for the vendor
and tagging the version). I then create the Boost.Build instructions to use
the library -- I actually tend to build even outside libraries with
Boost.Build as it makes for easier standardization of the build product. My
deveopers either run the standard fetch+build+install script or build the
library directly, and automatically, with bjam. But I decide, and
standardize, what they do.

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

No :-(

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