Re: [jamboost] Boost.Build design document

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-23 01:25:56

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

> How about this as the modified sequence then:
>
> 1. We attempt to load "boost-build.jam" by searching from the current
> invocation directory up to the root of the file-system and in the paths
> specified by BOOST_BUILD_PATH. Within this, one invokes the "boost-build"
rule
> to indicate where the Boost.Build system files are, and to load them.
> 2. If the Boost.Build system isn't loaded yet we error and exit,
giving
> brief instructions on possible errors.
> 3. We attempt to load "project-root.jam" by searching from the current
> invocation directory up to the root of the file-system. When found its
> location is noted as the PROJECT_ROOT.
> 4. Finally we load the "Jamfile" in the invocation directory. There
are
> various spellings considered when finding the "Jamfile", the pattern for
the
> name must fit: (J | j)amfile[.jam].

Great! Why don't you make the appropriate changes to architecture.html?

> >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).
>
> Doesn't 2.4 have changes to deal with VisualC? Like reading the registry
to
> setup it up within jam?

I think that's just one of Craig McPheeters' or Matt Armstrong's extensions.
We'll probably want to fold most of those in, but I don't think they're in
Perforce Jam yet.

> Don't know about wanting to change it, as all users are different :-) As
for
> expecting the ability to change it... currently there is a JAMFILE
variable
> that does this, so a user familiar with Jam-MR might expect that
> functionality.

With make people often keep several Makefiles in one directory, and invoke
them with "-f". I guess we'd better keep JAMFILE.

> >> 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
> >"[Jj]amfile.jam".
>
> I definitely want to use extensions ;-]
>
> Is that "$(JAMFILE)" the variable or "JAMFILE" all caps?

The latter, but I'm not convinced of it.

> One though about "include"... We are going to need to abstract out the
include
> functionality so that we can check for multiple includes, and found not
found.
> AFAIK the module code does that already but we would not be able to use it
in
> Jambase.

So what? We load up the build system soon enough. IMO everything should be a
module, except maybe the first file.

> I'd also like to have a variable setup in the included file scope
> that tells it where the file is located. That way the PROJECT_ROOT
variable is
> not needed and if one ever needs to generate absolute paths relative to
the
> current file it's easily done. It might look something like:
>
> rule include-file ( file : paths * )
> {
> if ! $(gINCLUDED($(file)))
> {
> BINRULE on $(file) = set-include-file-location ;
> SEARCH on $(file) = $(paths) ;
> gINCLUDED($(file)) = TRUE ;
> local CWD ;
This ^^^^^^^^ will hide the CWD generated by
set-include-file-location.
Perhaps you meant "module local CWD"?

> include $(file) ;
> }
> return $(gINCLUDED($(file))) ;
> }
>
> rule set-include-file-location ( file : path )
> {
> CWD = $(path:D) ;
> }
>
> ... That's just a sketch, there is additional checking code needed to
handle
> not finding the file.
>
> This way it means that the boost-build.jam file could be as simple as:
>
> boost-build $(CWD)/tools/build ;
>
> A better name than "CWD" would be good though :-\

Yah.

-D