Comments on: End user or development-oriented build system?

By: boris

boris — Fri, 18 Apr 2008 10:31:00 +0000

You can split a makefile into several parts (not sure you can do this with Makefile.am though) but you will still have to treat it as one makefile because of the shred variable scope. Here is an example. Let's say you have two makefile parts, one for the library and one for the test. The library makefile has something along these lines:



CPPFLAGS:= -DFOO

 

libfoo.so: foo.o bar.o

  $(CXX) $(CPPFLAGS) -o $@ $^

And the test makefile looks similar:



CPPFLAGS:= -DTEST

 

test: test.o libfoo.so

  $(CXX) $(CPPFLAGS) -o $@ $^

Then you have the master makefile which includes the two. The problem is that the second makefile overwrites the CPPFLAGS variable defined in the first makefile. The common way to resolve this would be to prefix each variable in a makefile fragment with its directory name, e.g., libfoo_CPPFLAGS, test_CPPFLAGS. This quickly gets out of hand in large projects where there might be hundreds of tests with deep subdirectory structure. How do you like the tests_cxx_parser_built_in_CPPFLAGS and tests_cxx_parser_validation_built_in_CPPFLAGS names? These would be actual names taken from one of my projects. Build addresses this in a scalable way by implementing variable scoping (so that included makefiles don't override includer's variables with the same names) and target-specific variables. But this can only be done in the latest version of GNU make (3.81) so an automake-like build system that has to support every version of make down to the ten-year-old 3.79 can't use this.

By: John Snelson

John Snelson — Thu, 17 Apr 2008 12:59:11 +0000

A single Makefile can be split up with includes, so it can always be as maintainable as a multiple Makefile model.

I guess I don’t believe there is such a thing as a developer or user oriented build system. Good build systems make both simple, and automake is the best I’ve found so far.

By: boris

boris — Tue, 15 Apr 2008 21:33:42 +0000

Hi John,

I think right now the Xerces-C++ 3.0.0 code base strikes a nice balance between the two extremes: one makefile for the whole project and one makefile for every directory. Currently it has one makefiles for each of these components: the library itself, tests, and examples. I don’t think the one giant makefile approach will scale in the long run for any substantial project.

I agree that automake provides support for more tasks though there is no reason a development-oriented build system can’t support them as well (in fact it can do a better job because it can rely on more powerful tools). The support for a wide range of platforms offered by automake, on the other, may be hard to replicate. Though I mention this tradeoff and the possible solution in the post.

Boris

By: John Snelson

John Snelson — Tue, 15 Apr 2008 19:39:22 +0000

I’m an automake lover, so I feel I have to jump in and defend it here. The way that Xerces-C uses automake is not really the best way to use it:

http://www.gnu.org/software/automake/manual/automake.html#Alternative

I use a single Makefile.am for building a number of my projects, and it’s just as easy to develop with as you describe the “build” system to be.

Automake also handles build dependencies, parallel builds, multiple build directories, and distribution creation and testing - all on more platforms than you’ve ever heard of.