This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] sim: generate build dependencies on the fly
- From: Mike Frysinger <vapier at gentoo dot org>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org, toolchain-devel at blackfin dot uclinux dot org
- Date: Tue, 12 Jul 2011 16:41:57 -0400
- Subject: Re: [PATCH] sim: generate build dependencies on the fly
- References: <1310436152-8693-1-git-send-email-vapier__46811.2245122485$1310436164$gmane$org@gentoo.org> <m3hb6rgu18.fsf@fleche.redhat.com>
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