Re: [jamboost] Wrapping up new design

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-08 11:12:53

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

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

> 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. Maybe "project-root.jam" would be better.

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

> Otherwise, everyting
> proceeds as with stock Jambase.

No argument with that part ;-)

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

> Do I understand the suggestion correctly?

I hope you do now ;-)

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

That JAM_TOOLSET business is an FTJam enhancement which I'm not sure I want
to keep. Does anyone have opinions?

> 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?

> > 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
> GLOB!)

Well, I guess I'm willing to allow different spellings. Make looks for
Makefile and then makefile, IIRC.

-Dave