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"
> 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,
> 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
> various spellings considered when finding the "Jamfile", the pattern for
> 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
> Doesn't 2.4 have changes to deal with VisualC? Like reading the registry
> 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
> expecting the ability to change it... currently there is a JAMFILE
> that does this, so a user familiar with Jam-MR might expect that
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
> >> 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".
> >you really want to be able to use extensions, let's also allow
> 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
> functionality so that we can check for multiple includes, and found not
> AFAIK the module code does that already but we would not be able to use it
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
> not needed and if one ever needs to generate absolute paths relative to
> 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
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
> 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 :-\
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