Re: bjam rationale...

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-16 08:30:30

Tompa wrote:
> David Abrahams <dave <at> boost-consulting.com> writes:
>> Here are some answers to the OP's question:
>> http://www.boost.org/tools/build/v1/build_system.htm#requirements
> 
> Fine, thank you! But, hmmm... What is it in that list of requirements that bjam
> does so much better than gnumake?

Well, let's see:

Q1.0: A developer adding a new library or test program must only have to
add simple entries naming the source files to a text file, and not have
to know anything about platform specific files. ...

A1.0: With GNU Make a developer needs to write the specific flags and
options used by all the compilers and operating systems (s)he is
targeting into her build actions. With Boost.Build, the developer
writes largely platform- independent build specifications.

Q1.5: ...The developer should not have to supply header dependency
information.

A1.5: Without help from external tools, GNU Make is not capable of
scanning for header dependencies, so the user has to use external tools
like perl scripts to handle that job.

Q2. There should be a very high likelihood of builds succeeding on all
platforms if a build succeeds on any platform. In other words, a
developer must not be required to have access to many platforms or
compilers to ensure correct builds

A2. See A1.0. Yes, it is possible to write "cross-platform" and
"cross-compiler" Makefiles. I have seen such systems, though, and they:
1. have always been limited to a small number of platforms and compilers
and 2. have been ugly an unmaintainable hacks because of the expressive
limitations of the make language. With Boost.Build you can write a
simple platform-independent build specification that usually "just
works" on every platform and compiler that Boost.Build supports.

Q3. A user or developer adding support for a new platform or compiler
should only have to add to a single file describing how to do the build
for that platform or compiler, and shouldn't have to identify the files
that will need to be built.

A3. In other words, it should be possible to plug in support for a new
operating system or compiler without modifying the project descriptions
(makefiles/Jamfiles, whatever). With GNU make that isn't supported
natively and is difficult to implement.

Q4. The build should rely only on tools native to the platform and
compiler, or supplied via the boost download.

A4. This appears to be less of a concern for Boost developers than it
was, but for various reasons people were at the time unwilling or unable
to install "external" tools like GNU Make, Perl, Python, etc. Somehow
building bjam from relatively simple codebase was acceptable.

Q5. The details of how the build is done for a particular platform or
compiler should be appropriate for that platform.

A5. GNU make provides no native support for controlling these details
without intruding on Makefiles/Jamfiles, and the previously mentioned
limitations of the make programming language make implementing it
difficult and ugly.

Q6. It should be possible to build multiple variants (e.g.
debug/release) of a single target.

A6. Same answer.

Q7. It should be possible to build multiple variants of multiple targets
with multiple compilers from a single build command.

A7. Same answer, multiplied by 10.

Q8. The build tools must be able to handle Boost growth issues such as
identified in Directory Structure proposals and discussion.

A8. These are old requirements; I don't remember what we had in mind
when we wrote that.

Q9. Support for dynamic and static linking should be included.

A9. Same answer as A7.

Q10. It should be relatively straightforward to add support for a new
compiler. In most cases, no modification of files used to describe
existing targets should be required.

A10. I think this is redundant with Q3.

Q11. Support for compiler- and variant-specific configuration for each
target

A12. Same answer as A9.

Q13. It should be possible to build targets into a directory unrelated
to the source directories (they may be read-only)

A14. I *think* GNU make can handle this easily enough if properly
engineered to do so. But while we're in the neighborhood, Google for
"recursive make considered harmful"

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
1