From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-08 12:04:24
David Abrahams wrote:
> > Then, the whole method will work like:
> > 0. If JAMBASE/BOOST_BUILD_PATH/BOOST_ROOT are empty, stock jambase is
> > loaded.
> I think at this point there are too many variables which have to be empty,
> and I'd like to reduce that number. I think this "crawl up" behavior is
> enough to eliminate the need for any of those to be set in the other case.
Do you mean to eliminate currect jambase selection semantics? I don't think
we need that -- IIRC, you've said yourself that most projects don't want to
specify build system location in top-level project config file.
> > 1. Jamrules is located
> Except that we should pick a different name. I want to leave the behavior
> of Jam alone for existing Jam projects if possible. In the semantics of the
> original Jam, the Jamrules file is loaded later, and as you know load order
Okay. And if that top-level file is not found, we resort to default jam
behaviour. This is exactly what Rene has implemented.
> > 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.
> That's a little imprecise. Perhaps we just want to say that
> project-root.jam has an opportunity to modify BOOST_BUILD_PATH.
Maybe so. But, in case project-root.jam contains something more that variable
assignments, boost-build.jam must be included before the first thing that
relies on boost-build.jam being already included. We can accomplish this with
a rule, but not with assignment to BOOST_BUILD_PATH.
> > 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.
> Putting it elsewhere should be allowable, to accomodate perverse, er, I
> mean diverse needs.
How can this be done taking in consideration my previous statement?
> That JAM_TOOLSET business is an FTJam enhancement which I'm not sure I want
> to keep. Does anyone have opinions?
I don't remember the exact list of changes, but I guess Jam won't work with
borland without them? If so, I think it's better to keep the changes.
> > 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 logic, though.
> If we use a different file for the crawl-up, this issue goes away, right?
> > For me, there're a little subjective. Makefiles existed for a long time,
> > without much complaints. Probabably, we should allow alternative
> > spelling?
> Well, I guess I'm willing to allow different spellings. Make looks for
> Makefile and then makefile, IIRC.
And for GNUMakefile sometimes. Alternative spelling become to look attractive
to me also.
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