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

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

----- Original Message -----
From: "Petr Ovchenkov" <ptr_at_[hidden]>
> Good morning David,

> In boost mail list was discussion 'configure' vs. 'jam'.

We've had various different discussions, including make vs. jam.

> I agree with most arguments that (configure; make) is not a good
> solution. When we work with C++, we must find C++-compiler-specific
> features. This features are near the same for one compiler
> (of the same version), and less platform-dependent.
> So the main configuration can be done (and really done) in boost/config/*
> By my opinion this is really the best solution.

I'm not worried about the config problem, so let's leave that aside.

> But when we need to build library, I prefer approach like use
> Boris Fomichev in STLport (I hope you familiar with STLport, and build
> it):

http://www.stlport.org/doc/thanks.html

> for main classes of compiler/platform we have a specific makefiles,
> with reuse of common part where it possible. If we use here common
> subset of make's, this will work on any system, without worry about
> make or jam or something else binaries.

"any" is a relative term. For example, it does not work on classic MacOS or
VMS. How important this is could be a matter for debate, however.

> As for me, I had first trouble with building jam (jam's build isn't
> clear in second pass, problem come from Jamfiles).

Sorry, I didn't understand that. What did you do, and what result did you
get?

> And second --- in
> understanding boost's Jamfiles.

What did you find difficult to understand?

The intention is for most of the Jamfiles to be very simple.
http://www.boost.org/libs/thread/build/Jamfile is a good example. If you are
crawling through the .jam files in the tools/build directory, I'm not
surprised you had trouble. That's a complicated program designed to make the
Jamfiles simple.

If I have failed to make even the Jamfiles simple, then I need to know more
about what you are having trouble with it, so I can fix that problem.

>  DA> 4. Boost-compatible license. Jam is free for any purpose, and
>  DA> freely redistributable.
>
> I really don't know any platform, where present C compiler, and no make
> or make-like program.

I mentioned two above. In any case, the different make-like programs all
have platform-specific quirks which make construction of a portable,
multi-compiler build-and-test system more difficult.

>  >> The complexity is near the same as with make. And presence in
>  >> system more than one compiler is a big problem for jam.
>
>  DA> Not at all. I use the boost build system with multiple compilers
>  DA> all the time.  Also, with the right Jam code (e.g. what's in
>  DA> Boost.Build) it is possible to specify build instructions in a
>  DA> platform- and compiler-neutral way, which makes writing Jamfiles
>  DA> for new projects much simpler.
>
> This not very easy when you have no experience with Jam, and something
> not work (or you want to specify a bit different behavior then default).

Like what? I may need to improve the documentation about how to do that.

>  >> Most people has a good experience with maintenance makefiles.
>
>  DA> Not me. Maybe somebody else has a better solution.
>
> May be the solution is to have two build structures, Jam- and
> make-based? And everybody will use what he/she like?

Are you volunteering? I don't think it's a good idea to have redundant build
systems, but I would be happy if someone would supply a different system
which satisfies all or most of the goals described at
http://www.boost.org/tools/build/build_system.htm#design_criteria. I would
simply retire Boost.Build if the alternative were easier to use and
maintain.

-Dave