Re: [jamboost] Wrapping up new design

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
> counts. 

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?

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.

-- Volodya