RFC: automatic dependency tracking for gdbserver
Pedro Alves
palves@redhat.com
Fri Dec 7 10:18:00 GMT 2012
On 12/03/2012 09:17 PM, Tom Tromey wrote:
> This patch applies the same automatic dependency tracking logic that gdb
> uses to gdbserver.
>
> The downside of this patch is that gdbserver dependencies will not be
> tracked unless the developer is using GNU make. On the other hand,
> we've had this same code in gdb for several years without any
> complaints.
>
> Comments?
Err, I love you? :-) Seriously, many thanks for doing this.
> +amd64-linux-ipa.o : amd64-linux.c
Spurious space -----^
> diff --git a/gdb/gdbserver/aclocal.m4 b/gdb/gdbserver/aclocal.m4
> index 7b546b7..55bf0d8 100644
> --- a/gdb/gdbserver/aclocal.m4
> +++ b/gdb/gdbserver/aclocal.m4
> @@ -106,4 +106,6 @@ AC_DEFUN([_AM_SUBST_NOTMAKE])
> # Public sister of _AM_SUBST_NOTMAKE.
> AC_DEFUN([AM_SUBST_NOTMAKE], [_AM_SUBST_NOTMAKE($@)])
>
> +m4_include([../../config/depstand.m4])
> +m4_include([../../config/lead-dot.m4])
> m4_include([acinclude.m4])
I think I'd mildly prefer having these listed explicitly in acinclude.m4,
so you can do just autoreconf on the command line or aclocal, without worrying
about forgetting -I (IIRC, ACLOCAL_AMFLAGS is actually ignored, because we're
not using automake). WDYT? I actually have a patch for GDB that does the same
to gdb's aclocal. See the second patch at:
https://github.com/palves/gdb/commits/aclocal
but I never posted it.
I do wonder why does acinclude.m4 use sinclude instead of include. I don't
see why you'd ever want those includes to silently fail.
--
Pedro Alves
More information about the Gdb-patches
mailing list