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