Boost logo

Boost :

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-09-13 08:13:13


David Abrahams wrote:
> Hi,
>
> On the Boost.Build list we were just discussing the fact that some
> people otherwise inclined towards Boost have chosen Scons over
> Boost.Build. It would be useful for us to understand some of the
> reasons why, if some of you wouldn't mind letting us know. No flames,
> please!

As far as the 'kernel' is concerned, I don't actually care as much
whether it is Scons or bjam or whatever. The single most important
aspect to me is the user interface, i.e. the language to write Makefiles
in.

I very much like the idea of making this language python. Unfortunately
even scons use a pretty non-pythonic approach for how to write
Sconscripts. But still, it is python, and thus easily extensible by
anybody with a minimal efford.

On the other hand, I find Jamfile syntax quite hard to read. I'm not
sure about the current state of its documentation, but the very fact
that it is a new language to learn is unfortunate.

I very much like the idea of a framework of toolchains as provided
by boost.build, and I have proposed to port it to scons in the past.

I also like the high-level approach of boost.build to provide a number
of (naming and file system) conventions to make the life of everybody
easier.

I don't understand the boost.build architecture well enough to know
which of the above is about bjam, and which about boost.build (or,
what boost.build really stands for in the first place).

I believe a good essay discussing the boost.build design from a user's
perspective would help. In particular, as boost.build is known as the
'build system for the boost libraries' (which may be a misconception)
it would help to understand the various components of boost.build, how
they interact, and how users can modify them to suite their own project's
needs.

For example:

* Can boost.build be used to build boost-unrelated projects ?
* Can boost.build be used to build python projects (or any language in fact) ?
* Is boost.build flexible enough to adapt to conventions that may exist when
   building software using language XYZ ?
* Can boost.build be used to package software (similar to python's distutils) ?
* How flexible is boost.build with respect to the build tree directory structure
   and file names ?

Regards,
                Stefan


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk