@Cam: Even though it’s virtual, it’s still a diamond. derived_impl still can call either derived::foo() or base_impl::foo(). Yes, derived::foo() is abstract - but at every invokation of foo() the compiler needs to actually find out which one you meant.

I do think that memory usage and compile time are excessive, but I’m not surprised the second example is simpler. I’d love to see the gcc team’s take on this….

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.

It will be hard to come up with a stand-alone test case since the generated code depends on the runtime library. But it is all open-source and the schema is publicly available so you will be able to reproduce this once the next version of XSD/e with support for delegation-based reuse is out. I can also provide makefiles, option files, etc. Let me know if you are interested.

That means whenever you call foo() on a derived_impl, gcc needs to disambiguate between base::foo() and base_impl::foo(). (Which is a tricky problem )

Your second solution does the disambiguation for the compiler - it specfies that a call to derived_impl can only use derived::foo, which will automatically forward to base_impl::foo

I’m surprised that the difference in memory usage and compile time is that big, though.

If you have a stripped sample project, I’d like to run it on various other compilers….

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.

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

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.