From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-08 06:37:33
David Abrahams wrote:
> > .... Crawling up appears
> > to be an overly smart solution.
> To me it seems relatively simple, and would eliminate a whole level of
> complication for users. Just look at the amount of traffic that has been
> generated by the question of how to get Jam installation right, and what
> environment variables need to be set. While I appreciate all the work
> people have done on installers, there are still platforms for which people
> need to compile Jam themselves.
> > Second, including Jamrules before loading boost build files might be a
> > problem. If Jamrules is to tell the location of boost-build system, what
> > rule will be used for that and where will it be defined?
> That rule can be in the Jambase.
Then, the whole method will work like:
0. If JAMBASE/BOOST_BUILD_PATH/BOOST_ROOT are empty, stock jambase is loaded.
1. Jamrules is located
2. If it contain a rule to tell where actual build system files are located,
those a loaded in the same way as with BOOST_BUILD_PATH. Otherwise, everyting
proceeds as with stock Jambase.
The only limitation in this method is that rule to specify build system
location need to be the first one in Jamrules -- not a big deal, I think.
Do I understand the suggestion correctly?
The essense of this approach is to allow stock jambase to discover that a
different boost system should be used without environment variable. But some
more details need to be polished. In particular, current jambase requires
"JAM_TOOLSET" variable to be set on win32, which defeats the purpose of the
scheme. However, it's possible to run that toolset-specific code after
Jamrules are read, as Jamrules are not likely to make use of variables such
as "CFLAGS" *inside* rules. It would require some rearrangement of jambase
> > David wrote:
> > > Maybe we should just dispense with "Jamfile" and go with "project.jam"
> > > (taking the place of Jamfile) and "project-config.jam" (taking the
> > > place of Jamrules).
> > I don't like the idea: "Jamfile" is good for me...
> > "Jamrules" is not so good name, however. But "project-config.jam" isn't
> > good either -- it suggests only simple configuration switched as content,
> > while it's okay to have rather elaborate rules in it. For me the best
> > name is "Jamglobals" (or "Jamglobal")
> Rene is arguing for filenames with extensions. His reasons are sound, it
> seems to me.
For me, there're a little subjective. Makefiles existed for a long time,
without much complaints. Probabably, we should allow alternative spelling? If
GLOB is available, we can do that easily. (Wow, just found a reason to have
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