Re: [PATCH] sim: generate build dependencies on the fly

[Tom Tromey <tromey@redhat.com>]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

Tom> Why is that?

Mike> it didnt seem to work :).  if the dependency generation step is done
Mike> inline with the compile step, how can we figure out the dependency
Mike> info of a header file that is generated ?  does gdb handle this and i
Mike> just missed it in its Makefile ?

Ok, I see.  I misunderstood what you meant.

GDB arranges for generated files to be built early, via order-only
dependencies.  Order-only dependencies ensure that merely touching one
of the generated files doesn't cause a global recompile.

The relevant code is down near the end of gdb/Makefile.in:

# Ensure that generated files are created early.  Use order-only
# dependencies if available.  They require GNU make 3.80 or newer,
# and the .VARIABLES variable was introduced at the same time.
@GMAKE_TRUE@ifdef .VARIABLES
@GMAKE_TRUE@$(all_object_files): | $(generated_files)
@GMAKE_TRUE@else
$(all_object_files) : $(generated_files)
@GMAKE_TRUE@endif


Tom> Finally I thought there was some problem with multiple entries in VPATH,
Tom> but I cannot find that in the docs.  Perhaps it is one of those ancient
Tom> incorrect memories.  It would bear testing with a non-GNU make.

Mike> sounds like all good reasons to use automake :).  otherwise all the
Mike> files in common/ need manual deps (like gdb does with files in
Mike> subdirs), and that semi-defeats the purpose of this in the first
Mike> place.

Yeah.  I am not actually sure how well Automake would currently handle
sources in "../common/".  Neither here nor there I guess.

Fedora includes the BSD make (yum install bmake); I assume other distros
do too.  So you could try a build with that.

Mike> yeah ... i didnt notice as my stuff all went through gcc for dep info.
Mike>  probably better to use $(srcroot)/depcomp.

You can edit the Makefile.in or generated Makefile slightly to test the
non-gcc3 path.

Tom