From: David Abrahams (david.abrahams_at_[hidden])
Date: 2003-03-05 06:15:47
Oliver, if you have questions about Boost.Build (especially our
recent work), it would be much better for you to ask on
jamboost_at_[hidden]; other people actually know more than I do
about some things...
"Schoenborn, Oliver" <Oliver.Schoenborn_at_[hidden]> writes:
> Thread seems to have stopped, but just found this in my drafts folder...
> looks like I hadn't sent it...
>> From: David Abrahams [mailto:david.abrahams_at_[hidden]]
>> > Sorry if this is not the right forum for this... Would anyone be able
>> > to list a few distinguishing features of bjam that made it a better
>> > choice than cmake, scons or other non-make descendants? I couldn't
>> > find any info of this nature in the boost.build online docs. Thanks
>> > in advance,
>> > Oliver
> Thanks for your reply Dave. I am looking for something slightly more
> specific. For instance,
> - File-specific flags seem easier to specify in jam than in cmake, I don't
> know yet about scons (by easier I mean more intuitive, if even possible).
> Cmake recently added support for file-specific flags (to compile one file
> with -O1, say) but it's still not as easy as saying "on target.o INCLUDE +=
We don't do stuff that way in Boost.Build. That's a low-level and
compiler-specific interface (well OK, maybe not INCLUDE, but CFLAGS
would be). The way you do things in Perforce Jam basically puts a
*very* thin layer of code between the user and the underlying build
system machinery, so what you're doing above by setting the INCLUDE
variable "on" a target is really operating on the bare metal. In
Boost.Build, we have a lot more abstraction going on: users almost
never handle the actual name of a bjam target directly -- instead,
they work with abstract target names which may then generate one or
more Jam targets (e.g. to build with multiple compilers, or multiple
build variants which are built to different locations).
> - Just running a test file seems easier in cmake and scons than in jam; say
> I compile a bunch of test files and then want to run them; in jam (don't
> know about bjam) you have to go through a rig-o-morole (sp?) with actions
> and rules, very counter-intuitive for such a simple and common activity.
Not if the actions and rules are in a library (of Jam code), which is
essentially what we have in Boost.Build. We have a rule called
unit-test which does just that.
> I'm sure there are tons of other specific differences. And, I'm sure
> that "easy" is different for everyone: some people would find the
> rules/actions in jam trivial, others might prefer python despite its
> slightly more character-full syntax. So side-by-side feature
> comparison could be really useful for people to determine which
> system seems "easier" to them (personally or as a team) and what
> limitations they are likely to face.
I don't know if a *side-by-side* comparison is appropriate; features
often don't map well between the systems. I don't know of any system
besides Boost.Build that supports truly compiler-independent build
descriptions, cross-project build dependencies, propagated build
However, some kind of introductory material which lays out the basic
concepts and capabilities of each system and shows some examples
would surely be useful -- to the developers, at the very least ;-)
> Before you ask, yes if I can find the time, I'd certainly be interested in
> doing such a comparison myself, but I wanted to make sure it didn't already
No it does not exist. I think it would be a great thing to do,
though. Please, have at it!
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk