Re: better dependency generation 2

[Nicholas Charles Leippe]

> Note there's only one recommended solution: the last one under the topic
> "Advanced Auto-Dependencies".  The subsections of that are both parts of
> that one solution.

Right.


>   ncl> While this is true for most projects, it is no longer true in the
>   ncl> case where some of the included headers are auto generated files.
> 
> Not so (in general, anyway).  We do a _lot_ of auto-generation of both
> header and source files here, and it's never been a problem.
> 
>   ncl> An incorrect build could result if the dependency between a .cpp
>   ncl> file and an autogenerated file (.ui.h if you've followed my
>   ncl> earlier threads) if the .h file's source has changed, and the
>   ncl> .cpp's dependency on the .h is new.
> 
> If the .cpp's dependency on the .h is new, then something in the .cpp
> file, or one of the other files that the .o depends on, must have
> changed to include it.
> 
> So, the target (.o) would _always_ be rebuilt and it will generate a
> new, correct set of dependencies for the next build.
> 
> 
> If you don't think so, please provide a more exact set of steps that
> would cause the problem you refer to, with filenames etc.
> 

Okay, how's this:

simple.ui.h is generated from simple.ui

foo.cpp didn't use simple.ui.h as of the
previous build run, thus foo.d does not
contain simple.ui.h as a prerequisite for
foo.o

Let's say that simple.ui is modified such that
the class definition is altered in a way that
results in a different class structure that
will not result in a link error, but will
result in incorrect behavior in the following.

Let's also say that foo.cpp was altered to now
use the class in simple.ui.h, so it now has a
#include "simple.ui.h" and uses it.

When make runs, foo.o may be built including
the old definition of simple.ui.h because there
is no edge between foo.cpp and simple.ui.h and
thus there is no way to gaurantee that simple.ui.h
is rebuilt before foo.o is updated.

Thus the final link could get a foo.o with the old
api, and simple.ui.o with the new api.

It would all come down to a crap shoot, which one
is built first, unless there is a rule to explicitly
force all autogenerated files to be rebuilt before
any other files.  (Which is how I solved my earlier
problems--by forcing the .d files to depend on the
autogenerated .ui.h files--but that causes a
re-exec of make and defeats the purpose of this
enhancement.)