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

[Mike Frysinger <vapier@gentoo.org>]

On Tue, Jul 12, 2011 at 15:48, Tom Tromey wrote:
>>>>>> "Mike" == Mike Frysinger writes:
> Mike> Generated header files still need to be manually tracked.
>
> Why is that?

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

a good example is the mn10300 subdir (which coincidentally, i'm pretty
sure is already missing dependency info and often fails to build in
parallel today).  the "sim-main.h" header is included by pretty much
all sim files and each arch must create it.  mn10300's sim-main.h
relies on the generated headers "itable.h" and "idecode.h" which come
from running ../igen/igen.  so they add those headers to
SIM_EXTRA_DEPS as most objects will depend on the files in that
existing.

> Mike> -VPATH = @srcdir@
> Mike> +VPATH = @srcdir@:$(srccom)
>
> The Autoconf manual lists various problems with VPATH.
>
> You can't use variable references in VPATH.

i read some info on that, but it sounded like the known issues were
worked around by configure.  such as empty vpath and "." entries.  but
i guess i didnt delve into the autoconf manual to double check.

> Also VPATH won't work properly with built sources.  I'm not sure if your
> patch relies on that or not.

the common subdir does generate one "sim-inline.c" file for a few
targets.  seemed to generate/build on my system, but i'm using
up-to-date GNU make, so that probably doesnt count.

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

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

> Mike> +depcomp = $(SHELL) $(srcdir)/../depcomp
>
> This seems like the wrong directory to me.
> I would have expected $(srcdir)/../../depcomp.

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