Re: [boost] Boost building with CMake

From: Larry Evans (cppljevans_at_[hidden])
Date: 2007-05-18 11:51:52

On 05/18/2007 11:09 AM, Dean Michael Berris wrote:
> 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. ;-)
> 

I don't see much difference unless you're just referring
to the amount of typing.  However, in that case,
you could just use gmake's include to "import"
a library of macros, somewhat like bjam's import.
Now as for as selecting different compilers and putting
the resuling .o and .a and .exe files in different
directories, this could also be done with gmake.  For
example:

MAIN ?= main
BUILD.dir ?= $(PROJECT.dir)/build
RELEASE.dir ?= $(PROJECT.dir)/release
###################
HOW=gcc
#HOW=gccv
#HOW=icc
#HOW=como
BUILD_HOW.dir:=$(BUILD.dir)/$(HOW)
VARIADIC.dir=/home/evansl/download/gcc/variadic-templates
VARISNAP.dir=$(VARIADIC.dir)/gcc-4.3-20070323
COMPILER.gcc=/usr/bin/g++-4.1
COMPILER.gccv=$(VARISNAP.dir)/install/bin/g++
COMPILER.src.gccv=$(VARIADIC.dir)/gcc-4.1.1
COMPILER.src.gcc=$(VARIADIC.dir)gcc-4.1.1-download/gcc-4.1.1-non-var/gcc-4.1.1
COMPILER.src.file=gcc/cp/pt.c
COMPILER.icc=/home/evansl/intel/cc/9.1.043/bin/icc
COMPILER.como=como

Of course you might be saying, "but that's so much typing", and
the natural response is, agin, gmake include.  With the help
of some perl or python utilities, you could so somthing like
the way bjam searches for the boost root:

   DIR.root := $(shell dirup_dir_file.pl $(PWD) root.imk)

When put inside a gmake file, this searches up in the paraent
directories until it finds root.imk (corresponding to
boost-root.jam, I guess).

Again, I know it seems a lot of behind the scenes work, but
no more so (really a lot less) than what bjam does.

The problem I had with this gmake include approach was that
I couldn't figure a way to emulate bjam's projects.  IOW,
bjam projects and the method for invoking them overcomes
, I guess, the problems with recursive Makes.  I've heard
recursive makes are a problem, but I don't really understand
all the details, but I can see one problem is the namespace
conflict.  IOW, all the macros in different recursions of
make would or might interfere.  Again I'm guessing.

In summmary, your example, at least to me, doesn't
illustrate a real advantage of bjam vs gmake.

-best regards,
Larry