Re: hidden dependencies

[Krzysztof Cieniuch]

Philip Guenther wrote:
> On Wed, Jan 19, 2011 at 5:26 AM, Warlich, Christof
> <address@hidden> wrote:
> ...
>   
> > > I'm very interested in this subject.  In my project we have generated
> > > code for rpc interfaces and corba plus there is perl tool that generates
> > > some xml files.
> > >       
> > Same with me, lots of generated (include) files, so gcc -MD can't track
> > the dependencies until the files are generted.
> >     
>
> What I did on a previous project that faced this was create an
> order-only dependency from each file that 'could' #include a generated
> .h file to that generated file.  That guarantees the files are created
> soon enough without requiring that everything be recompiled if a
> generated header file is updated.
>
>
> Philip Guenther
>
> _______________________________________________
> Help-make mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-make
>   
I was thinking about doing this but didn't liked  side effect that 
sources would be generated always even
if one rebuilds some completely unrelated module.

Note that there are corner cases (I admit very unlikely to happen) that 
you may endup with broken incremental build.
e.g.
Let say that I modify idl file that would result with changes in object 
sizes and at the same time I modify some client code and add include for 
that
generated header file. Now I run parallel build if dependency is missing 
it may happen that my client code will be compiled with older version of
generated header file. Note that previous build didn't generated that 
dependency since a that point client code didn't yet depend on that header.
The same issue would be if you're adding new code that includes 
generated headers.

So it is important to have correct dependency information before running 
build kinda chicken and egg problem.

Agree that order only dependency would solve at least any issues with 
clean builds.

Krzysztof