Re: [jamboost] Wrapping up new design

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-01-08 11:34:11

On 2002-01-08 at 02:37 PM, ghost_at_[hidden] (Vladimir Prus) wrote:

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

I was working on this over the weekend, and currently having working as
follows:

1. If BOOST_BUILD_PATH or BOOST_ROOT are set we load boost-build.jam
2. Or if we find PROJECT_CONFIG we load that, which calls a "boost-build
<dir>" rule to load boost-build.jam.
3. Or if no PROJECT_CONFIG is found we use the stok 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.

With the above I have that call at the bottom of my PROJECT_CONFIG, I do it
that way so I can set things like TOOLS, STLPORT* vars to default values
before the system is included. And by moving the inclusion of "Jamfile" from
allyourbase.jam to Jambase you could call it anywhere in the PROJECT_CONFIG
file.

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

Yep, that first sentence seems to sum it up well :-)

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

And for the same reasons Toon wants the GLOB... for maintenance convenience... 
user convenience is the only reason to have extensions. (which is what I
mentioned before :-)

I think Toon put best, and I'll rephrase, it's all about future laziness ;-]

PS. I'll put up my current Jambase for comments inthe files section.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]