Re: [boost] Boost building with CMake

From: Dean Michael Berris (dmberris_at_[hidden])
Date: 2007-05-18 12:09:09

Hi Stefan,

On 5/18/07, Stefan Seefeld <seefeld_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>
> > Not to throw dirt at GNU Make, but it's just too hard and too painful
> > to maintain complex project builds with it. Whether by hand or with
> > auto-tools.
> >
> > Compare that to the trivial Jamfiles that are smart enough to figure
> > out what to do when you say:
> >
> > exe main : main.cpp ;
> >
> > And be cross-platform right off the bat.
>
> I don't think it's fair to compare (GNU) make with boost.build,
> as 'make' itself operates more on the level of bjam. I'm fairly
> positive that something akin to boost.build could be written on
> top of 'make', too, i.e. a set of makefiles, together with
> conventions how to use them.
>

I think this was the idea in CMake, which made makefiles (among other
things) for you. I don't think Boost.Build does what CMake does, in
the sense that the Boost.Build system itself does the building while
CMake will rely on an external/different build system to actually do a
build. Please correct me if this assessment is wrong.

Now comparing 'bjam' and 'make' would be moot because they're apples
and oranges: two completely different things which did things
differently. However, since they both do the actual build by invoking
compilers, linkers, archivers, code generators, etc. then let's say we
should be able to compare the way you configure them to run: Makefiles
and Jamfiles.

If there was ever a direct comparison between a Makefile and a
Jamfile, then I'd like to see a link. If there isn't one yet, please
let me try to give one trivial comparison between the Makefile and
Jamfile -- one Makefile generated by hand, and another Jamfile
generated by hand.

Makefile:

CC=g++
CFLAGS=-Wall

%.o: %.cpp
    $(CC) $(CFLAGS) -c $^

main: main.o some_other_file.o
    $(CC) $(CFLAGS) -o $< $^

Jamfile:

exe main : main.cpp some_other_file.cpp ;

Like I said, apples and oranges. ;-)

> In fact, as much problems as there exist with (GNU) make, the
> single most important advantage it has is that there are more people knowing
> it (its syntax, semantics, flaws, and ways to work with and around them).
>
> Throwing that advantage away shouldn't be taken lightly.
>

I don't mean to turn this into a philosophical debate, but just
because people know how to do mental math doesn't mean they wouldn't
benefit from knowing how to use a calculator. We're not throwing away
the advantage of people knowing how to do mental math, but we're not
also saying that everyone should use a calculator.

So the reason Boost.Build+Boost.Jam are the way they are is most
likely because it was meant to be different from Make and attempts to
do a better job than Make. It is direct competition but it was never
meant to be built to take over the world of build systems -- at least
as how I see it, it's an alternative which actually works and in some
cases (nay, most I would say) does better than Make.

> (And, as it happens, the single most important disadvantage I see
> with bjam is exactly the same: new syntax, new (and grossly underdocumented)
> semantics, and very few people who really understand all that.)
>

How would a different syntax be a disadvantage? I'm sorry, it's like
saying since Python has a different syntax from C++ is that the syntax
is a disadvantage.

The undocumented semantics can be addressed and people are actually
starting to do something about it. Please see the Boost.Build mailing
list(s) if you want to be part of that discussion.

If it's not obvious yet, *I don't like Make because I've been burn too
many times with it*. Even though Boost.Jam and Boost.Build use a
different syntax, that didn't stop me (and others) from using it. And
I actually welcome the change from syntax, much like how C++'s syntax
is a welcome change from Pascal.

Again, I think it boils down to recognizing what you need and
expressing what needs to be done with a tool you're familiar with. I
guess it's "to each his own". :-)

FWIW.

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]