Re: [jamboost] Wrapping up new design

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 
logic, though.

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

- Volodya