Re: [boost] Re: Boost.Build on IBM, SGI & HP

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-11 08:42:54

----- Original Message -----
From: "Eric Ford" <eford_at_[hidden]>

> Personally... Never heard of it until boost build wanted it.  Had to
> read documentation on the build system, find it, install it, generally
> a nussance (made me think "what makes those high brow boost people
> think they're so special that they can do things their own way?").

See my previous post.
Also, see http://www.boost.org/tools/build/build_system.htm#design_criteria,
which I should have referred to from that post.

> Having to learn a new tool (not so bad when everything works out of
> the box, but a real problem when things don't just work) is a major
> deterent to using the software.

I appreciate your frustration with that. I think it's a problem that can be
fixed as we gain experience making the transition to using Boost.Build...
but it will only work if people like you who have problems will report them
so that we can work out the kinks.

> The boost documentation is long.

Are you referring to http://www.boost.org/tools/build/, or to
http://www.boost.org/tools/build/build_system.htm ?

Much of the latter is really a design document; I had to write it just so I
could understand the software I was constructing. I intend to improve the
documentation a bit as the work progresses, but I am not sure how short it
can really be. Any system which handles jobs as complicated as that of
building software will neccessarily require some non-trivial amount of
documentation.

> Originally, I just ignored anything that required jam.  Then the
> thread library motivated me to give it a chance.  The build failed, so
> I gave up.  Then someone posted a fix for the threads library on linux
> with gcc, so I decided to give it another try.  Jam was so
> complicated, I decided it was easier to identify the files that needed
> to be compiled in and do it myself rather than using jam.

What in particular did you find to be complicated?

> It's never
> build an entire library for me.  I have no interest in learning it's
> syntax, file layout, etc., especially when only one library uses it.

The Python library also uses it, regex also has a Jamfile although I'm not
sure John is ready to fully transition to using Boost.Build at this point.
The Boost regression tests can now be run through Jam, meaning that if you
change some piece of Boost source, only the dependent tests will be run. The
goal has always been that all of the Boost libraries would eventually use
Boost.Build for whatever products must be built.

> Finally, whoever thought of asking users to type the ridiculus
> -ftools/build/allyourbase.jam should be sentanced to years of
> debugging.

I guess I'd better brush up on my bug-hunting skills ;-)

> Why can't it just be 'jam'

It can, and it will with the next release of the build system. For a while I
wasn't ready to make any changes to the Perforce Jam source. Now that we
have the freedom to do so, we can make some small changes to the builtin
Jambase file that allow the system to find the code that's currently in
allyourbase.jam.

I do need some feedback about what mechanism would be acceptable for finding
the build system source. A .jamrc file has been suggested, but that begs the
same question: "where is the .jamrc file located?" In the absence of better
suggestions, I intend to use an environment variable setting.

If you want to eliminate the specification of TOOLS, you can just set it in
an environment variable in your .cshrc, autoexec.bat, or equivalent. In the
meantime, your platform's shell scripting system surely allows you to make a
simple wrapper around the executable that does just what you want. I have a
.bat file that looks like this:

----- bjam.bat -----
@echo off
c:\boost\tools\build\jam_src\bin.ntx86\jam -fc:\boost\tools\build\allyourbas
e.jam %*
-----------------

> or 'jam gcc'? Even 'jam
> -sTOOLS="gcc"' seems too complicated.

Interesting. You're suggesting that a pseudotarget with the same name as the
toolset should build all targets that would be built with that toolset? I
like that idea, but there are a few problems with it:

1. you still wouldn't have such a simple syntax for "build this specific
target with GCC". Still, it's a good idea to make simple jobs as simple as
possible.

2. Some global list of the available toolsets would still have to be
available, so that the targets can be generated (there is a procedural
machanism in the build system which generates all of the appropriate targets
based on the values of TOOLS). Not a big deal, but it means you couldn't
just drop in a new toolset definition and start using it without updating
this variable.

3. The time it takes to run Jam is in part proportional to the number of
targets generated, so Jam would be doing more work than if it only generated
targets for gcc. Not a big deal, really: I think most of the time is spent
scanning headers, doing dependency analysis, etc., and none of that is done
for targets whose build is not requested.

So, I guess there are no serious objections to your idea. I think a
combination of the two approaches makes sense. Users could set TOOLS and
also use your technique. The only limitation is that if gcc is not in TOOLS,
then "jam gcc" would do nothing other than complain that there was no such
target as "gcc". I don't think that's a serious limitation, because most
users will not be adding toolset definitions.

Thanks, this is the sort of feedback I need!

> I imagine there's some good reason why jam was chosen (I don't
> normally follow the build threads), but as a user I would much prefer
> the familiar ./configure; make.  Jam annoys me, but I'm still willing
> to use libraries for which it works the first time.  I think direct
> links to the executables (as opposed to the current indirect links)
> should be provided on the web page of any library which requires it.
> Sorry for being so negative, but I assume you want an honest answer.

Aside from being condemned to years of debugging (that part seemed
unneccessarily ad-hominem), I appreciated hearing your thoughts. I would
like to hear more from other users.

-Dave