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

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-10-11 12:21:57

> Also, FYI, the use of Jam was supposed to solve many of the make problems
> described here:
> http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html, for which I
> don't know of any simple solution. Indeed, the paper seems to imply that
> there is no effective way to use make unless ALL build components are
> included in a single Makefile. Jam allows relatively non-intrusive addition
> of subprojects to any project.

Thanks for that reminder.  While I appreciate the attempt to avoid multi-pass
make for libraries that do things like generate .h files, it has never been a
big issue in my mind.  Once you accept multi-pass make, the one makefile problem
disappears and instead you have a makefile at each level in the directory along
with some globally included settings (eg: borland_config.mak, vcc_config.mak,
...).  When you add a file to a library you add the name to the Makefile in that
directory.  There are usually other tools and techniques that minimize a
developer's need to run make from the top of the tree (like pointing at a
pre-built build) so that it just doesn't create an issue.

From my view, this is all moot for Boost b/c I don't currently see a need for
multi-pass make at all -- simple recursion from /libs would be enough.  Multiple
passes might be required if you started storing the header files for a library,
for example, under the /libs/LIBNAME directory and installing the /boost
directory as the first step of the build.  The rest of the variations
(compilers, static versus dynamic, etc) can be handled by the aforementioned
included make files.

BTW, I'm not arguing against jam, just saying that a nice build system can be
acheived with Make.  However, unless someone can show by contribution this
system, I think effort would be better applied to working out the issues with
jam...

Jeff