Re: [jamboost] Building b/jam...

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-11-06 17:16:16

[2002-11-06] David Abrahams wrote:

>Rene Rivera <grafik666_at_[hidden]> writes:
>
>> I'm done with the first pass at the new build scripts for b/jam. They
are:
>> 
>> * build.bat; Bootstrap build on Windows command.com shell. Currently
>> supports:
>> 
>> - Detection of: Borland(BCC5) tools - tested; CodeWarrior 8 tools -
>> tested; MSVC in the three variants of C++/98, Studio, and .NET
>> (untested)
>
>How does it detect them? Environment? Registry?

Checks common locations for things like bcc.exe, vcvars*.*, etc.; and the
environment when appropriate. I started looking at trying to read the
registry so that may be possible. The BAT script will get better as I figure
out more things to do in BAT.

>> - Bootstraps both jam and mkjambase (if needed). Doesn't bootstrap
the
>> grammar because of the generally missing "yyacc" script on Windows.
>
>Good.
>
>> * build.sh; Bootstrap build on Unix type SH shell, supports:
>> 
>> - Detection of: GCC tools - tested on Linux; MacOSX Drawin GCC tools
-
>> tested; Intel Linux - untested; VisualAge C/C++ - untested.
>> - Bootstraps jam, mkjambase, and the gramar.
>
>Nice, though I worry about bootstraping the grammar...

It only bootstraps jambase or the grammar when they dont already exist. So
in the normal distribution that won't happen. To get it to bootstrap that
one would have to delete the files.

>> * build.jam; Does the regular building, supports:
>> 
>> - All the current toolsets we have regular Boost.Build support for.
But
>> I've only tested the ones mentioned above.
>> - Automatic detection of bison or yacc. Prefers bison over yacc.
>
>I don't think it's best to prefer bison. The problem is that bison
>generates files which require alloca, which isn't available on all
>systems. If someone rebuilds bjam with bison, and then checks in, he
>will scuttle buildability for other people.

OK, didn't know that... so I'll change it to prefer yacc, it's just swapping
two lines :-)

>Maybe it would be best to disable building the grammar unless you
>supply explicit flags. We might want to distinguish between developers
>and build-to-install people.

The building is a bit smarter than the current Jamfile, and only builds when
the source is out of date (something that should also not happen in the
regular user distribution). But I can certainly add a flag for this. How
about a "--build-grammar" ?

>> - Doesn't remove files for things it can't build normally, like the
>> grammar files when it can't find bison/yacc, or
>> mkjambase(jambase.c).
>
>That's very important.
>
>> - Has a single "dist" target for building the various distribution
>> parts: source archive, binary archive, and single binary.
>> - Autodetection of RPM tool to build the rpm archive as part of the
dist
>> target.
>
>Nifty!
>
>> The scripts are targeted mostly at enduser building, and as such us
>> developers have to do the extra typing. Users just do either
>> "./build.sh" or ".\build.bat".
>
>OK. What's the extra typing look like?

Developers would have to use bjam for building, and the command would be
like:

./bin.linuxx86/bjam -f build.jam -sBOOST_JAM_TOOLSET=gcc [ "dist",
options, whatever else we think of ]

>> The one thing I could not keep compatible in the still present
>> Jamfile was the RPM building. This is because the command to build
>> b/jam is embedded in the boost-jam.spec. So to build RPMs you must
>> use these new scripts. If we can't live with this I can try and make
>> changes to "Jamfile" to get that working.
>
>I'm not sure I understand what the consequences of this are.

Simple... we can't use the current Jamfile to build the RPMs. To allow that
I'd have to make changes to build.jam, Jamfile, and boost-jam.spec.

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