Boost logo

Boost-Build :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-22 14:19:55

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>

> Initialization:
> We check the name used to invoke Jam, and if the name is not the
> Boost.Jam invocation we continue with the execution of the Perforce
> Jambase.
> Otherwise, when we recognize a Boost.Jam invocation, we:
> 1. We search for "project-root.jam" from the invocation directory up
> the root of the file-system. When found its location is noted as the
> PROJECT_ROOT. If not found we exit with an appropriate error message.
> 2. We load "project-root.jam", within it one can call the
> rule to indicate where to find the Boost.Build files. The "boost-build"
> does two things: a) pushes the given path onto the BOOST_BUILD_PATH (if
> given), b) attempts to load the build system.
> 3. If the build system isn't loaded yet, load it at this time by
> "boost-build".

Any interesting project-root.jam file will want to use rules made available
by the build system (e.g. the modules.jam), so the above isn't really a
viable alternative.

> 4. Finally we load the Jamfile in the invocation directory.
> This procedure has the effect of allowing both simple and complex setup.
> the "project-root.jam" it's possible to obtain control of the build system
> both before the system is loaded and before the Jamfile is loaded.

How would this work when multiple users are working on the same project but
the Boost.Build source is located in different places? One possibility is
that in this project, the user is responsible for supplying a
project-root.jam which invokes boost-build, and then for invoking the real
"project-root.jam". However, I'm not fond of this idea. I suggest instead
that the project-root directory (or any other directory above the Jamfile?)
may contain boost-build.jam, which may be used to load the build system.
That would also handle the problem above; if we can't find boost-build.jam
above the Jamfile, we assume that BOOST_BUILD_PATH is set up, and let it
take effect.

[BTW, I'm getting less and less fond of relying on environment variables for

At that point, we proceed to load project-root.jam. How's that?

> ...some thoughts:
> To answer your FTJam concern, I would suggest we dump the FTJAm Jambase
> entirely and use the Perforce one instead. Since we are only using it to
> jam itself we should only need the functionality from the release. Or does
> Jamfile in jam_src use FTJam functionality?

I think that it does not. However, some of the toolset description files
make use of the FTJam JAM_TOOLSET variables (e.g. intel-win32 uses VISUALC).
I don't think that really means anything, though. Hmm, the FTJam changes
does make it easier to build Jam with various compilers, e.g. Borland.

> Naming conventions... given that we want "clean up" the use of user
> configurable variables we should define some naming conventions.
> for the initialization there would need to be two variables for possibly
> overriding the default names for "project-root.jam" and "Jamfile".

Really? Do we really need to allow that?
If we need to support any environment variables, I guess those would be the
ones. As I said, environment settings are leaving me with a bad taste.

> With that in mind one question is wether we want to support multiple file
> names? That is do we search for both "Jamfile" and "project.jam"?

I think it makes sense to look for "[Jj]amfile" and possibly "JAMFILE". If
you really want to be able to use extensions, let's also allow



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at