Re: [boost] jam build system

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-22 12:32:49

----- Original Message -----
From: "John Maddock" <John_Maddock_at_[hidden]>

> Dave,
>
> I've been trying out the new jam build system but so far haven't persuade
> anything to build!
>
> First off in the docs you say:
>
> "Jam can be found at http://www.perforce.com/jam/jam.html. "
>
> But doesn't the current system require FTJam?

Yes, I'm just polishing a new release that will reflect recent changes.

> BTW it would very helpful if the latest FTJam sources were mirrored as
part
> of boost (perhaps as a "vendor branch"?).

Can it be done automatically? I'm not sure how David Turner feels about
this, but FTJam is currently in the Perforce public depot, and he's been
talking about an independent CVS host at SourceForge. The potential for
things getting out of synch is not to be underestimated.

> The -fallyourbase-path option is a complete pain, not least because this
> must surely be about the least intuitive name I've every seen,
> "boost-base.jam" maybe would be better?

"complete" pain? I agree that it's ugly, but it sounds like you're
exaggerating a little bit. We're looking at alternatives (one involves
compiling allyourbase.jam into Jam so you don't need the -f option), but in
the meantime I suggest you write yourself a little batch file or shell
script that hides the need for the -f option.

> The docs lack any "end user" documentation - I'm not talking about boost
> users writing jamfiles here, just step by step instructions for particular
> compilers - I do appreciate though that this is a fair amount of work.

Can you give me some idea what you mean by "step by step instructions for
particular compilers"? Users shouldn't have to know much of anything about
particular compilers to use the system. That's the goal, at least.

> You say:
>
> "To use the build system, the following must be located in your project's
> root directory, or in directories given by the path variables indicated
> below. "
>
> But why?  Can't these files be located based upon the location of
> allyourbase.jam?

No, they can't. The location of the file that's used in place of Jambase is
not available in the Jam code.

> Failing that why _two_ environment variables instead of
> one?

Because I'm not sure how best to organize things, yet. It isn't at all clear
to me how people will want to use it. They may want to replace the toolset
definitions while using the boost-supplied boost-base.jam, for example. I
figure that with a little bit of use, some of these issues will become
clear.

> Even better can't boost-jam support files be installed in a system
> wide location?

I'm open to suggstions, but don't really want to attack any cross-platform
issues that can't be solved within Jam itself. When you're making a project
within boost, you shouldn't have to think about this stuff. See
libs/python/build/Jamfile for an example. It just works.

> Moving on to trying out jam, I notice that the version checked into the
> main branch lacks the sample project sub-directories

That wasn't announced and it's not ready for primetime yet. I'm just putting
that version together. Okay, I'm checking in what I have, since you seem to
be interested.

I think the sample project subdirectories in the build-development branch of
the top-level build modules will still work; I'm not sure that I want to
keep them, though. I'm looking for more reliable and comprehensive ways to
test the system.

>, likewise the python Jamfile seems to be missing.

That's rather strange. Oh, it's been on the build-development branch. I just
put it on the main trunk.

I also checked in a preliminary status/Jamfile for doing all the boost
regression tests. It seems to work, but requires an FTJam feature that's not
in the latest official release. I've uploaded an archive of these
pre-release Jam sources to
http://groups.yahoo.com/group/boost/files/ftjam-src.tgz

> So I tried the thread library instead - the
> initial problem was caused by the fact that the compiler couldn't find the
> boost include files, opening up the Jamfile I see:
>
>         ## Requirements ##
>         : <include>c:/boost
>           <include>..
>
> which I eddited to point to my boost install - but that can't be the right
> way to do this can it?

No, it's not. I checked in a fix for Bill's Jamfile last week. Did you try
getting his stuff from the thread-inital branch?

> However I still couldn't get the thread library to build - it compained
> about multithreading support not being turned on (#error's in the
headers),
> so I suppose I need to do something here but what?

Try what I checked in on thread-initial. It worked for me last week.

> Moving on to the regex Jamfile you've just checked in - I can build with
> gcc (at last!) - but not as you say with Borland or VC6 - for these when
> building a dll I need to define BOOST_RE_BUILD_DLL - how do I ensure that
> this gets defined when I need it, and only when I need it?

Well, you need to add it to the requirements for the target. Requirements
come in a section following the sources, and might look like this for your
case:

: <msvc><*><define>BOOST_RE_BUILD_DLL <borland><*><define>BOOST_RE_BUILD_DLL

> BTW going back to the gcc build of regex, I see only a debug static lib
> build, even though it's under a "runtime-link-dynamic" sub-dirtectory,

How you link to the runtime is independent of whether you're building a
static or dynamic library, right?

> specifying -sBUILD=release gets me the release version though, but
> shouldn't this be produced anyway - or am I missing something?

The default build is debug only. You can change what's built by default for
any target by adding it to the default-build sectioni that follows the
requirements section:

  : debug release

will build the debug /and/ release variants.

  : debug release <runtime-link>static/dynamic

will build versions that link to the runtime both statically and
dynamically.

HTH,
Dave