Re: A build system using ``Recursive Make Considered harmful''

[Tom Tromey]

>>>>> "Scott" == Scott A Crosby <address@hidden> writes:

Scott> First, 'make clean' builds dependencies before doing any
Scott> cleaning.

This is a known flaw in the dependency tracking implementation
recommended by GNU make.  You can read about this problem, and the
fix, in the Automake dependency tracking history:

    http://sources.redhat.com/automake/dependencies.html

Scott> I have not tested it with program-built code. IE. the case
Scott> where one program is run to generate code that is later
Scott> compiled.  (IE: './genCode interp.spec > interp.c') My problem
Scott> is is with how and when do I create and include the dependency
Scott> file on the generated code.  ('interp.c') Suggestions/fixes
Scott> welcome.

There's a kind of deep, generic problem here.  It isn't really easy to
fix, at least not if you want automatic dependency tracking as well.
Automake takes one particular hacky approach (BUILT_SOURCES).  This is
also discussed in the paper.

Scott> $(patsubst %.c,%.d,$(filter %.c,$(SRC))) : %.d: %.c
Scott> [ ... ]
Scott>                 $(CC) -MM $(CPPFLAGS) $< \

Your approach only works when you use gcc and GNU make.  Our
experience in automake (and this is also in the paper) is that this is
insufficient.  In fact, this was one of the most frequently reported
problems with automake 1.4.

Scott>   2. 'gcc -MM' was futzing up filenames/pathnames in its
Scott> output, if you gave it something with a path 'foo/bar.cpp' the
Scott> automatically generated dependency file would make dependencies
Scott> for 'bar.cpp' and lose the directory prefix: 'foo/'. This
Scott> should be reported to GCC.

gcc 3.0 includes more options to control the dependency output.  These
were introduced because I lobbied for them; I thought they were
important for cooperation with automake.  One of the new options,
`-MT', can be used to tell gcc exactly what target to generate in the
dependency output.  This should suffice for your use.

Scott> Also, is this a bug in GCC that should be reported?

Not any more.

Scott> -- The future
Scott> But, if we fix these warts, maybe we can convince people to
Scott> trash the more crazy build systems that do use recursive make?
Scott> Its nice for things to 'just work', and in complete
Scott> parallelization.
Scott> So, what do you think?

I think it is great that your work confirms the results in the
Recursive Make Harmful paper.  Since automake is probably the craziest
of the crazy build systems, I think it is reasonable that it look in
this direction in the future.  And, in fact, we've been planning this
as (possibly) one of the major new features in a later automake
release.  (Actually there is already some support for it already,
though not as nice as we would like.)  Unfortunately, automake
operates under many constraints which means that we won't be able to
use your code as-is.  Instead we'll need our own implementation.

Another approach, of course, is to get rid of automake and do
something new.  Unless you are willing to relax the constraints (e.g.,
require GNU make and gcc), I think that would be as much work as
reimplementing automake.  Even assuming GNU make it would still be a
significant effort.

Tom