Re: Update rebuild rules in non-automake directories.

Re: Update rebuild rules in non-automake directories.

[Ralf Wildenhues]

In <http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02137.html>, I posted a
first set of changes against GCC trunk that update the rebuild rules for
files generated by the autotools.  This patch was already approved, but
I wanted to defer its application until I had done the respective one
for src.  Now's the time.

In the process, I found files I had omitted in that first patch.  So
here is a second patch, against src (and overlapping with GCC), that I
am seeking approval for.  I will then apply both combined, to both GCC
and src, where they apply.  AFAICS they fix rules throughout the
binutils-gdb parts of src (i.e., what the git copy covers).

Notes:

- The intl and libdecnumber change is to please make implementations
where '#' comments does not extend across backslash-newline.  It was
forgotten from the same (already posted) patch against GCC.

- The gdb change also fixes a bug with regeneration triggered by the
automake-generated makefile below the gnulib directory.  This was
mentioned on this list a while ago, but I can't find a reference to it
now.  Is there a PR attached to it that I should mention in the
ChangeLog?

There are changes unique to src (etc/) and to gdb in this patch, as well
as changes to files shared; a build system maintainer for GCC and src
should be able to approve this rather trivial patch, I hope.

Thanks,
Ralf

intl/ChangeLog:
2009-07-28  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in (aclocal_deps): New variable.
	($(srcdir)/aclocal.m4): Use it, for portable makefile syntax.

libdecnumber/ChangeLog:
2009-07-28  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in (aclocal_deps): New variable.
	($(srcdir)/aclocal.m4): Use it, for portable makefile syntax.

etc/ChangeLog:
2009-07-28  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in (AUTOCONF, configure_deps): New variables.
	($(srcdir)/configure): New rule.
	* configure.in: Accept --enable-maintainer-mode, set and
	substitute MAINT accordingly.

gdb/ChangeLog:
2009-07-28  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in (ACLOCAL, ACLOCAL_AMFLAGS, aclocal_m4_deps):
	New variables.
	($(srcdir)/aclocal.m4, am--refresh): New rules.

diff --git a/etc/Makefile.in b/etc/Makefile.in
index 9642e07..66b4446 100644
--- a/etc/Makefile.in
+++ b/etc/Makefile.in
@@ -231,6 +231,12 @@ maintainer-clean realclean:   distclean
 Makefile: $(srcdir)/Makefile.in $(host_makefile_frag) $(target_makefile_frag)
 	$(SHELL) ./config.status
 
+AUTOCONF = autoconf
+configure_deps = $(srcdir)/configure.in
+
+$(srcdir)/configure: @MAINT@ $(configure_deps)
+	cd $(srcdir) && $(AUTOCONF)
+
 ## these last targets are for standards.texi conformance
 dist:
 check:
diff --git a/etc/configure.in b/etc/configure.in
index 7285d37..6b94aac 100644
--- a/etc/configure.in
+++ b/etc/configure.in
@@ -4,6 +4,21 @@ AC_INIT(Makefile.in)
 
 AC_PROG_INSTALL
 
+# Command-line options.
+# Very limited version of AC_MAINTAINER_MODE.
+AC_ARG_ENABLE([maintainer-mode],
+  [AC_HELP_STRING([--enable-maintainer-mode],
+                 [enable make rules and dependencies not useful (and
+                  sometimes confusing) to the casual installer])],
+  [case ${enable_maintainer_mode} in
+     yes) MAINT='' ;;
+     no) MAINT='#' ;;
+     *) AC_MSG_ERROR([--enable-maintainer-mode must be yes or no]) ;;
+   esac
+   maintainer_mode=${enableval}],
+  [MAINT='#'])
+AC_SUBST([MAINT])dnl
+
 AC_SUBST(datarootdir)
 AC_SUBST(docdir)
 AC_SUBST(htmldir)
diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 7659a8f..6874e09 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -1222,6 +1222,48 @@ stamp-h: config.in config.status
 config.status: configure configure.tgt configure.host
 	$(SHELL) config.status --recheck
 
+ACLOCAL = aclocal
+ACLOCAL_AMFLAGS = -I gnulib/m4
+aclocal_m4_deps = \
+	configure.ac \
+	gnulib/m4/extensions.m4 \
+	gnulib/m4/gnulib-common.m4 \
+	gnulib/m4/gnulib-comp.m4 \
+	gnulib/m4/include_next.m4 \
+	gnulib/m4/longlong.m4 \
+	gnulib/m4/memchr.m4 \
+	gnulib/m4/memcmp.m4 \
+	gnulib/m4/memmem.m4 \
+	gnulib/m4/onceonly_2_57.m4 \
+	gnulib/m4/stdint.m4 \
+	gnulib/m4/string_h.m4 \
+	gnulib/m4/wchar.m4 \
+	../config/extensions.m4 \
+	../config/lead-dot.m4 \
+	../config/proginstall.m4 \
+	../bfd/bfd.m4 \
+	../config/acinclude.m4 \
+	../config/override.m4 \
+	../config/gettext-sister.m4 \
+	../config/lib-ld.m4 \
+	../config/lib-prefix.m4 \
+	../config/lib-link.m4 \
+	../config/acx.m4 \
+	../config/tcl.m4 \
+	../config/depstand.m4 \
+	../config/lcmessage.m4 \
+	../config/codeset.m4
+
+$(srcdir)/aclocal.m4: @MAINTAINER_MODE_TRUE@ $(aclocal_m4_deps)
+	cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
+
+# automatic rebuilding in automake-generated Makefiles requires
+# this rule in the toplevel Makefile, which, with GNU make, causes
+# the desired updates through the implicit regeneration of the Makefile
+# and all of its prerequisites.
+am--refresh:
+	@:
+
 force:
 
 # Documentation!
diff --git a/intl/Makefile.in b/intl/Makefile.in
index 96211ff..3dd0b7f 100644
--- a/intl/Makefile.in
+++ b/intl/Makefile.in
@@ -211,16 +211,28 @@ config.status: $(srcdir)/configure
 $(srcdir)/configure: @MAINT@ $(srcdir)/aclocal.m4 $(srcdir)/configure.ac
 	cd $(srcdir) && $(AUTOCONF)
 
-$(srcdir)/aclocal.m4: @MAINT@ $(srcdir)/configure.ac \
-	$(srcdir)/../config/codeset.m4 $(srcdir)/../config/gettext.m4 \
-	$(srcdir)/../config/glibc21.m4 $(srcdir)/../config/iconv.m4 \
-	$(srcdir)/../config/intdiv0.m4 $(srcdir)/../config/inttypes-pri.m4 \
-	$(srcdir)/../config/inttypes.m4 $(srcdir)/../config/inttypes_h.m4 \
-	$(srcdir)/../config/lcmessage.m4 $(srcdir)/../config/lib-ld.m4 \
-	$(srcdir)/../config/lib-link.m4 $(srcdir)/../config/lib-prefix.m4 \
-	$(srcdir)/../config/nls.m4 $(srcdir)/../config/po.m4 \
-	$(srcdir)/../config/progtest.m4 $(srcdir)/../config/stdint_h.m4 \
-	$(srcdir)/../config/uintmax_t.m4 $(srcdir)/../config/ulonglong.m4
+aclocal_deps = \
+	$(srcdir)/configure.ac \
+	$(srcdir)/../config/codeset.m4 \
+	$(srcdir)/../config/gettext.m4 \
+	$(srcdir)/../config/glibc21.m4 \
+	$(srcdir)/../config/iconv.m4 \
+	$(srcdir)/../config/intdiv0.m4 \
+	$(srcdir)/../config/inttypes-pri.m4 \
+	$(srcdir)/../config/inttypes.m4 \
+	$(srcdir)/../config/inttypes_h.m4 \
+	$(srcdir)/../config/lcmessage.m4 \
+	$(srcdir)/../config/lib-ld.m4 \
+	$(srcdir)/../config/lib-link.m4 \
+	$(srcdir)/../config/lib-prefix.m4 \
+	$(srcdir)/../config/nls.m4 \
+	$(srcdir)/../config/po.m4 \
+	$(srcdir)/../config/progtest.m4 \
+	$(srcdir)/../config/stdint_h.m4 \
+	$(srcdir)/../config/uintmax_t.m4 \
+	$(srcdir)/../config/ulonglong.m4
+
+$(srcdir)/aclocal.m4: @MAINT@ $(aclocal_deps)
 	cd $(srcdir) && $(ACLOCAL) -I ../config
 
 config.h: stamp-h1
diff --git a/libdecnumber/Makefile.in b/libdecnumber/Makefile.in
index 4160795..de91f6f 100644
--- a/libdecnumber/Makefile.in
+++ b/libdecnumber/Makefile.in
@@ -94,9 +94,13 @@ config.status: $(srcdir)/configure
 $(srcdir)/configure: @MAINT@ $(srcdir)/aclocal.m4
 	cd $(srcdir) && $(AUTOCONF)
 
-$(srcdir)/aclocal.m4: @MAINT@ $(srcdir)/../config/stdint.m4 \
-	$(srcdir)/../config/warnings.m4 $(srcdir)/../config/override.m4 \
+aclocal_deps = \
+	$(srcdir)/../config/stdint.m4 \
+	$(srcdir)/../config/warnings.m4 \
+	$(srcdir)/../config/override.m4 \
 	$(srcdir)/configure.ac
+
+$(srcdir)/aclocal.m4: @MAINT@ $(aclocal_deps)
 	cd $(srcdir) && $(ACLOCAL) -I ../config
 
 config.h: stamp-h1

Re: Update rebuild rules in non-automake directories.

[Paolo Bonzini]

On 07/28/2009 08:17 PM, Ralf Wildenhues wrote:
> +	gnulib/m4/extensions.m4 \
> +	gnulib/m4/gnulib-common.m4 \
> +	gnulib/m4/gnulib-comp.m4 \
> +	gnulib/m4/include_next.m4 \
> +	gnulib/m4/longlong.m4 \
> +	gnulib/m4/memchr.m4 \
> +	gnulib/m4/memcmp.m4 \
> +	gnulib/m4/memmem.m4 \
> +	gnulib/m4/onceonly_2_57.m4 \
> +	gnulib/m4/stdint.m4 \
> +	gnulib/m4/string_h.m4 \
> +	gnulib/m4/wchar.m4 \

It would be nice to use something like

autom4te --trace 'AC_DEFUN:$%' --language Autoconf m4/gnulib-comp.m4 | 
sed -n 's/^gl_FILE_LIST://p' | tr ' ' '\n' | grep ^gnulib/m4/

but anyway the patch is okay.

Paolo

Re: Update rebuild rules in non-automake directories.

[Tom Tromey]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

Ralf> - The gdb change also fixes a bug with regeneration triggered by the
Ralf> automake-generated makefile below the gnulib directory.  This was
Ralf> mentioned on this list a while ago, but I can't find a reference to it
Ralf> now.  Is there a PR attached to it that I should mention in the
Ralf> ChangeLog?

I don't recall one.  If you searched bugzilla and didn't find it, then
don't worry about it.

Ralf> gdb/ChangeLog:
Ralf> 2009-07-28  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
Ralf> 	* Makefile.in (ACLOCAL, ACLOCAL_AMFLAGS, aclocal_m4_deps):
Ralf> 	New variables.
Ralf> 	($(srcdir)/aclocal.m4, am--refresh): New rules.

It seems a little odd to have a rule to rebuild aclocal.m4 when there is
no rule to rebuild configure.  Are you planning to add that?  (I don't
think this affects whether the patch is ok -- it is still an improvement
over the present situation.)

Tom

Re: Update rebuild rules in non-automake directories.

[Samuel Bronson]

At Tue, 28 Jul 2009 13:03:34 -0600,
Tom Tromey wrote:
> It seems a little odd to have a rule to rebuild aclocal.m4 when there is
> no rule to rebuild configure.  Are you planning to add that?  (I don't
> think this affects whether the patch is ok -- it is still an improvement
> over the present situation.)

You mean --enable-maintainer-mode doesn't already do that?

Re: Update rebuild rules in non-automake directories.

[Tom Tromey]

>>>>> "Samuel" == Samuel Bronson <naesten@gmail.com> writes:

>> Tom Tromey wrote:
>> It seems a little odd to have a rule to rebuild aclocal.m4 when there is
>> no rule to rebuild configure.  Are you planning to add that?  (I don't
>> think this affects whether the patch is ok -- it is still an improvement
>> over the present situation.)

Samuel> You mean --enable-maintainer-mode doesn't already do that?

I thought it did, but I couldn't find the code in gdb/Makefile.in.
It does for automake-managed directories, of course.

Tom

Re: Update rebuild rules in non-automake directories.

[Ben Elliston]

On Tue, 2009-07-28 at 20:17 +0200, Ralf Wildenhues wrote:

> - The intl and libdecnumber change is to please make implementations
> where '#' comments does not extend across backslash-newline.  It was
> forgotten from the same (already posted) patch against GCC.

The libdecnumber change is fine.

Thanks,
Ben

Re: Update rebuild rules in non-automake directories.

[Ralf Wildenhues]

Hello Tom, Samuel,

* Samuel Bronson wrote on Wed, Jul 29, 2009 at 12:23:42AM CEST:
> At Tue, 28 Jul 2009 13:03:34 -0600, Tom Tromey wrote:
> > It seems a little odd to have a rule to rebuild aclocal.m4 when there is
> > no rule to rebuild configure.

I indeed managed to overlook that.  Thank you.

> > Are you planning to add that?  (I don't
> > think this affects whether the patch is ok -- it is still an improvement
> > over the present situation.)

I will resubmit the gdb part of the patch with that rule.

> You mean --enable-maintainer-mode doesn't already do that?

Nope.  This Makefile.in is not created by automake.

About the changes that should go upstream, are you saying I should get
them accepted upstream before they can go into gdb / src?  Please note
that several of the changes are specific to GCC/src; for example,
m4_rename_force would require boehm-gc to move to Autoconf 2.64, or to
employ the workaround we add to override.m4, somewhere in its code.

Thanks,
Ralf

Re: Update rebuild rules in non-automake directories.

[Samuel Bronson]

At Wed, 29 Jul 2009 07:30:50 +0200,
Ralf Wildenhues wrote:
> About the changes that should go upstream, are you saying I should get
> them accepted upstream before they can go into gdb / src?

Just so you know, I can't *say* anything of the kind; I can only
suggest. And I wasn't trying to do anything of the sort. But I expect
that question was for Tom (who can say that kind of thing, but doesn't
seem to have been, afaict)?

Re: Update rebuild rules in non-automake directories.

[Tom Tromey]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

Ralf> About the changes that should go upstream, are you saying I should get
Ralf> them accepted upstream before they can go into gdb / src?  Please note
Ralf> that several of the changes are specific to GCC/src; for example,
Ralf> m4_rename_force would require boehm-gc to move to Autoconf 2.64, or to
Ralf> employ the workaround we add to override.m4, somewhere in its code.

We already dealt with this, but for the record, I think it is best to at
least make an attempt to send things upstream before checking in a local
divergence.  This helps make future imports less hairy.  If upstream
takes too long, for whatever reason, then IMO it is usually ok to just
go ahead (particularly for configury stuff, which tends not to be very
invasive).

Tom

Re: Update rebuild rules in non-automake directories.

[Ralf Wildenhues]

* Tom Tromey wrote on Tue, Jul 28, 2009 at 09:03:34PM CEST:
> >>>>> "Ralf" == Ralf Wildenhues writes:
> 
> Ralf> gdb/ChangeLog:
> Ralf> 2009-07-28  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
> Ralf> 	* Makefile.in (ACLOCAL, ACLOCAL_AMFLAGS, aclocal_m4_deps):
> Ralf> 	New variables.
> Ralf> 	($(srcdir)/aclocal.m4, am--refresh): New rules.
> 
> It seems a little odd to have a rule to rebuild aclocal.m4 when there is
> no rule to rebuild configure.  Are you planning to add that?  (I don't
> think this affects whether the patch is ok -- it is still an improvement
> over the present situation.)

Respin of the gdb part including rebuild rules for configure and
config.in.  FWIW, the $(srcdir)/ prefixes before files that are
mentioned both as targets as well as as prerequisites are needed to let
some BSD make implementations find them portably.  Anyway the whole
thing is pretty much copied from Automake rules.

OK?

As to Paolo's comment, I didn't see how to easily bring autom4te output
into the mix, and also don't trust distros to have autom4te versioned as
consistently as some have autoconf and autoheader.

Thanks,
Ralf

gdb/ChangeLog:
2009-07-30  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in (ACLOCAL, ACLOCAL_AMFLAGS, aclocal_m4_deps)
	(AUTOCONF, configure_deps, AUTOHEADER): New variables.
	($(srcdir)/aclocal.m4, $(srcdir)/configure, $(srcdir)/config.in)
	(am--refresh): New rules.
	(stamp-h, config.status): List config.in and configure including
	$(srcdir)/ prefix.

Index: gdb/Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.1091
diff -u -r1.1091 Makefile.in
--- gdb/Makefile.in	3 Jul 2009 12:06:35 -0000	1.1091
+++ gdb/Makefile.in	30 Jul 2009 21:01:54 -0000
@@ -1212,16 +1212,69 @@
 	  $(SHELL) config.status
 
 config.h: stamp-h ; @true
-stamp-h: config.in config.status
+stamp-h: $(srcdir)/config.in config.status
 	CONFIG_HEADERS=config.h:config.in \
 	  CONFIG_COMMANDS="default depdir" \
 	  CONFIG_FILES= \
 	  CONFIG_LINKS= \
 	  $(SHELL) config.status
 
-config.status: configure configure.tgt configure.host
+config.status: $(srcdir)/configure configure.tgt configure.host
 	$(SHELL) config.status --recheck
 
+ACLOCAL = aclocal
+ACLOCAL_AMFLAGS = -I gnulib/m4
+aclocal_m4_deps = \
+	configure.ac \
+	gnulib/m4/extensions.m4 \
+	gnulib/m4/gnulib-common.m4 \
+	gnulib/m4/gnulib-comp.m4 \
+	gnulib/m4/include_next.m4 \
+	gnulib/m4/longlong.m4 \
+	gnulib/m4/memchr.m4 \
+	gnulib/m4/memcmp.m4 \
+	gnulib/m4/memmem.m4 \
+	gnulib/m4/onceonly_2_57.m4 \
+	gnulib/m4/stdint.m4 \
+	gnulib/m4/string_h.m4 \
+	gnulib/m4/wchar.m4 \
+	../config/extensions.m4 \
+	../config/lead-dot.m4 \
+	../config/proginstall.m4 \
+	../bfd/bfd.m4 \
+	../config/acinclude.m4 \
+	../config/override.m4 \
+	../config/gettext-sister.m4 \
+	../config/lib-ld.m4 \
+	../config/lib-prefix.m4 \
+	../config/lib-link.m4 \
+	../config/acx.m4 \
+	../config/tcl.m4 \
+	../config/depstand.m4 \
+	../config/lcmessage.m4 \
+	../config/codeset.m4
+
+$(srcdir)/aclocal.m4: @MAINTAINER_MODE_TRUE@ $(aclocal_m4_deps)
+	cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
+
+AUTOCONF = autoconf
+configure_deps = $(srcdir)/configure.ac $(srcdir)/aclocal.m4
+$(srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(configure_deps)
+	cd $(srcdir) && $(AUTOCONF)
+
+AUTOHEADER = autoheader
+$(srcdir)/config.in: @MAINTAINER_MODE_TRUE@ $(configure_deps)
+	cd $(srcdir) && $(AUTOHEADER)
+	rm -f stamp-h
+	touch $@
+
+# automatic rebuilding in automake-generated Makefiles requires
+# this rule in the toplevel Makefile, which, with GNU make, causes
+# the desired updates through the implicit regeneration of the Makefile
+# and all of its prerequisites.
+am--refresh:
+	@:
+
 force:
 
 # Documentation!

Re: Update rebuild rules in non-automake directories.

[Tom Tromey]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

Ralf> Respin of the gdb part including rebuild rules for configure and
Ralf> config.in.

Ralf> OK?

Yes, this is OK.  Thank you very much.

Tom

Re: Update rebuild rules in non-automake directories.

[Jan Kratochvil]

Hi Ralf,

currently
	make -C src/gdb check//unix

will do
	mkdir -p -- testsuite.unix/.
	running CONFIG_SHELL=/bin/sh /bin/sh ./configure ...
	/bin/sh: ./configure: No such file or directory

while for gdb-6.8 it did
	mkdir -p -- testsuite.unix/.
	running /bin/sh ../.././gdb/testsuite/configure ...
	configure: loading cache .././config.cache
	...

Tried to debug it now a bit but the code is really not an easy one to read,
could you please check it?


Thanks,
Jan

Re: Update rebuild rules in non-automake directories.

[Ralf Wildenhues]

Hello Jan,

* Jan Kratochvil wrote on Wed, Aug 26, 2009 at 05:17:19PM CEST:
> currently
> 	make -C src/gdb check//unix
> 
> will do
> 	mkdir -p -- testsuite.unix/.
> 	running CONFIG_SHELL=/bin/sh /bin/sh ./configure ...
> 	/bin/sh: ./configure: No such file or directory
> 
> while for gdb-6.8 it did
> 	mkdir -p -- testsuite.unix/.
> 	running /bin/sh ../.././gdb/testsuite/configure ...
> 	configure: loading cache .././config.cache
> 	...
> 
> Tried to debug it now a bit but the code is really not an easy one to read,
> could you please check it?

How exactly do you configure and build the tree, and in which directory
are you in when you specify the above command?  I'm getting

  mkdir -p -- testsuite.unix/.
  running CONFIG_SHELL=/bin/sh /bin/sh ../../../src/gdb/testsuite/configure ...
  configure: loading cache ../config.cache
  ...

when running 'make check//unix' in $build which lives outside of src;
that seems to do the desired thing.  Do you build in-tree?

Thanks,
Ralf

Re: Update rebuild rules in non-automake directories.

[Jan Kratochvil]

Hi Ralf,

On Wed, 26 Aug 2009 18:46:36 +0200, Ralf Wildenhues wrote:
> when running 'make check//unix' in $build which lives outside of src;
> that seems to do the desired thing.  Do you build in-tree?

You are right it works from a build directory outside of the source directory.

I am using (and it worked for GDB before):
	cd src; ./configure; make; make -C gdb check//unix


Thanks,
Jan

Re: Update rebuild rules in non-automake directories.

[Ralf Wildenhues]

* Jan Kratochvil wrote on Wed, Aug 26, 2009 at 06:54:10PM CEST:
> On Wed, 26 Aug 2009 18:46:36 +0200, Ralf Wildenhues wrote:
> > when running 'make check//unix' in $build which lives outside of src;
> > that seems to do the desired thing.  Do you build in-tree?
> 
> You are right it works from a build directory outside of the source directory.
> 
> I am using (and it worked for GDB before):
> 	cd src; ./configure; make; make -C gdb check//unix

OK.  I will look into this.  But I have a more general question first:
so far I was under the impression that GCC and all of src always only
builds outside the source directory (and consequently, I never tested
that for the autotools upgrade).  Which parts of src can (could) be
built in-tree and for which parts is that usually done?

Just so that I can avoid more issues.

Wait ... did you start off with a clean tree after the autotools update,
or did you run 'cvs up; make' with a tree that was built before the
update?  The latter might show spurious issues.

Thanks,
Ralf

Re: Update rebuild rules in non-automake directories.

[Eli Zaretskii]

> Date: Wed, 26 Aug 2009 19:38:07 +0200
> From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
> Cc: gdb-patches@sourceware.org
> 
> But I have a more general question first:
> so far I was under the impression that GCC and all of src always only
> builds outside the source directory (and consequently, I never tested
> that for the autotools upgrade).  Which parts of src can (could) be
> built in-tree and for which parts is that usually done?

I don't know about the other parts of src, but GDB always supported
in-tree builds, even though we advise in README to do it outside the
source tree:

    You can build GDB right in the source directory:

	  cd gdb-6.3
	  ./configure
	  make
	  cp gdb/gdb /usr/local/bin/gdb     (or wherever you want)

    However, we recommend that an empty directory be used instead.
    This way you do not clutter your source tree with binary files
    and will be able to create different builds with different
    configuration options.

Re: Update rebuild rules in non-automake directories.

[Jan Kratochvil]

On Wed, 26 Aug 2009 19:38:07 +0200, Ralf Wildenhues wrote:
> But I have a more general question first: so far I was under the impression
> that GCC and all of src always only builds outside the source directory

I have been so far aware about this requirement only for GCC (SVN).


> Which parts of src can (could) be built in-tree and for which parts is that
> usually done?

Doing it for both binutils and gdb, therefore at least these basic dirs:
bfd binutils gas gdb gprof include ld libdecnumber libiberty opcodes readline

Someone else may give more insight on it.


> Wait ... did you start off with a clean tree after the autotools update,
> or did you run 'cvs up; make' with a tree that was built before the
> update?  The latter might show spurious issues.

I have verified now the problem is reproducible with fresh new:
	cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co gdb


Thanks,
Jan

obtaining configure args from config.status (was: Update rebuild rules in non-automake directories.)

[Ralf Wildenhues]

* Jan Kratochvil wrote on Wed, Aug 26, 2009 at 06:54:10PM CEST:
> On Wed, 26 Aug 2009 18:46:36 +0200, Ralf Wildenhues wrote:
> > when running 'make check//unix' in $build which lives outside of src;
> > that seems to do the desired thing.  Do you build in-tree?
> 
> You are right it works from a build directory outside of the source directory.
> 
> I am using (and it worked for GDB before):
> 	cd src; ./configure; make; make -C gdb check//unix

Thanks.  The difference in Autoconf that caused this is that a srcdir of
`pwd` is now simplified to '.' which wasn't done before, and thus the
check//% rule in gdb fails when trying to run
  /path/to/src/gdb/testsuite/config.status --recheck

in the
  /path/to/src/gdb/testsuite.$$vardots/

directory.  Hmm, that's ugly.

This is caused/exposed by this change in Autoconf quite a while ago:
597bc15a76f08893e1e0c372cbd96732ba7b7ed6

| +2005-08-16  Stepan Kasal  <kasal@ucw.cz>
| +
| +       When building in place, set srcdir="."; suggested by Tim Van Holder.
| +
| +       * lib/autoconf/general.m4 (_AC_INIT_SRCDIR): Do this; to recognize
| +         build in place, we need ac_pwd, and thus have to AC_REQUIRE ...
| +       (_AC_INIT_DIRCHECK): ... this macro and AC_DEFUN both of them.
| +       * lib/autoconf/status.m4 (_AC_SRCDIRS): Fix a comment: srcdir="."
| +         does not mean "no --srcdir option".

Also, I'm not sure I really like relying on a rather obscure feature of
running 'config.status --recheck' from a different directory.

Paolo, we could "fix" this by overriding _AC_INIT_SRCDIR in override.m4,
but I'm not really sure the old behavior is all that desirable either.
Instead, I'll try to revive my `config.status --config' patch upstream;
for the moment, let's parse --version output to get the configuration,
and add a FIXME note to fix things up later.

The one bit I think is a little awkward in the makefile rule is that the
eval could do harm to unusual settings of $(SHELL), and it's not clear
how to quote that.  For the rest, I think I got the quoting safe.

The previous behavior explicitly invoked each config.status, where the
--recheck avoids recursion.  I think just invoking the topmost
gdb/testsuite/configure should be sufficient, as it should recurse
to the other sub configures and do the right thing for them.

OK to apply?

Cheers,
Ralf

Fix parallel check//% rule in gdb.

2009-08-29  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* gdb/Makefile.in (check//%): Parse 'config.status --version'
	output to recreate the configuration from the testsuite directory,
	rather than running 'config.status --recheck' from a different
	build directory.  Let configure do the recursion rather than
	doing it manually.


diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 90c285f..7bc02cd 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -888,6 +888,7 @@ check: force
 # a shell that expands alternations within braces.  If GNU make is not
 # used, this rule will harmlessly fail to match.  Used FORCE_PARALLEL to
 # prevent serialized checking due to the passed RUNTESTFLAGS.
+# FIXME: use config.status --config not --version, when available.
 check//%: force
 	@if [ -f testsuite/config.status ]; then \
 	  rootme=`pwd`; export rootme; \
@@ -896,14 +897,14 @@ check//%: force
 	  variant=`echo "$@" | sed 's,^[^/]*//,,'`; \
 	  vardots=`echo "$$variant" | sed 's,/,.,g'`; \
 	  testdir=testsuite.$$vardots; \
-	  if [ ! -f $$testdir/Makefile ]; then \
-	    (cd testsuite && find . -name config.status) | \
-	    sed s,/config.status$$,, | sort | while read subdir; do \
-	      $(SHELL) $(srcdir)/../mkinstalldirs $$testdir/$$subdir && \
-	      (cd $$testdir/$$subdir && \
-	       $(SHELL) $$rootme/testsuite/$$subdir/config.status \
-		 --recheck && \
-	       $(SHELL) ./config.status); done; \
+	  if [ ! -f $$testdir/Makefile ] && [ -f testsuite/config.status ]; then \
+	    configargs=`cd testsuite && ./config.status --version | \
+	      sed -n -e 's,"$$,,' -e 's,^ *with options ",,p'`; \
+	    $(SHELL) $(srcdir)/../mkinstalldirs $$testdir && \
+	    (cd $$testdir && \
+	     eval $(SHELL) "\"\$$rootsrc/testsuite/configure\" $$configargs" \
+			   "\"--srcdir=\$$rootsrc/testsuite\"" \
+	     ); \
 	  else :; fi && cd $$testdir && \
 	  $(MAKE) $(TARGET_FLAGS_TO_PASS) \
 	    RUNTESTFLAGS="--target_board=$$variant $(RUNTESTFLAGS)" \

Re: obtaining configure args from config.status

[Paolo Bonzini]

> Paolo, we could "fix" this by overriding _AC_INIT_SRCDIR in override.m4,
> but I'm not really sure the old behavior is all that desirable either.
> Instead, I'll try to revive my `config.status --config' patch upstream;
> for the moment, let's parse --version output to get the configuration,
> and add a FIXME note to fix things up later.

I prefer even this patch to overriding. :-)

Paolo

Re: obtaining configure args from config.status (was: Update rebuild rules in non-automake directories.)

[Ralf Wildenhues]

Ping <http://sourceware.org/ml/gdb-patches/2009-08/msg00592.html>

* Ralf Wildenhues wrote on Mon, Aug 31, 2009 at 10:29:39PM CEST:
> OK to apply?

> Fix parallel check//% rule in gdb.
> 
> 2009-08-29  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
> 
> 	* gdb/Makefile.in (check//%): Parse 'config.status --version'
> 	output to recreate the configuration from the testsuite directory,
> 	rather than running 'config.status --recheck' from a different
> 	build directory.  Let configure do the recursion rather than
> 	doing it manually.
> 
> 
> diff --git a/gdb/Makefile.in b/gdb/Makefile.in
> index 90c285f..7bc02cd 100644
> --- a/gdb/Makefile.in
> +++ b/gdb/Makefile.in
> @@ -888,6 +888,7 @@ check: force
>  # a shell that expands alternations within braces.  If GNU make is not
>  # used, this rule will harmlessly fail to match.  Used FORCE_PARALLEL to
>  # prevent serialized checking due to the passed RUNTESTFLAGS.
> +# FIXME: use config.status --config not --version, when available.
>  check//%: force
>  	@if [ -f testsuite/config.status ]; then \
>  	  rootme=`pwd`; export rootme; \
> @@ -896,14 +897,14 @@ check//%: force
>  	  variant=`echo "$@" | sed 's,^[^/]*//,,'`; \
>  	  vardots=`echo "$$variant" | sed 's,/,.,g'`; \
>  	  testdir=testsuite.$$vardots; \
> -	  if [ ! -f $$testdir/Makefile ]; then \
> -	    (cd testsuite && find . -name config.status) | \
> -	    sed s,/config.status$$,, | sort | while read subdir; do \
> -	      $(SHELL) $(srcdir)/../mkinstalldirs $$testdir/$$subdir && \
> -	      (cd $$testdir/$$subdir && \
> -	       $(SHELL) $$rootme/testsuite/$$subdir/config.status \
> -		 --recheck && \
> -	       $(SHELL) ./config.status); done; \
> +	  if [ ! -f $$testdir/Makefile ] && [ -f testsuite/config.status ]; then \
> +	    configargs=`cd testsuite && ./config.status --version | \
> +	      sed -n -e 's,"$$,,' -e 's,^ *with options ",,p'`; \
> +	    $(SHELL) $(srcdir)/../mkinstalldirs $$testdir && \
> +	    (cd $$testdir && \
> +	     eval $(SHELL) "\"\$$rootsrc/testsuite/configure\" $$configargs" \
> +			   "\"--srcdir=\$$rootsrc/testsuite\"" \
> +	     ); \
>  	  else :; fi && cd $$testdir && \
>  	  $(MAKE) $(TARGET_FLAGS_TO_PASS) \
>  	    RUNTESTFLAGS="--target_board=$$variant $(RUNTESTFLAGS)" \

Re: obtaining configure args from config.status

[Jan Kratochvil]

Hi Ralf,

On Mon, 31 Aug 2009 22:29:39 +0200, Ralf Wildenhues wrote:
> +	     eval $(SHELL) "\"\$$rootsrc/testsuite/configure\" $$configargs" \
> +			   "\"--srcdir=\$$rootsrc/testsuite\"" \

do I miss anything if here would be just such simple quoting?

	     eval $(SHELL) $${rootsrc}/testsuite/configure "$$configargs" \
			   --srcdir=\$${rootsrc}/testsuite \

Other parts of Makefile.in already cannot cope with spaces in $srcdir.



Thanks,
Jan

Re: obtaining configure args from config.status

[Ralf Wildenhues]

* Jan Kratochvil wrote on Tue, Sep 08, 2009 at 06:28:26PM CEST:
> On Mon, 31 Aug 2009 22:29:39 +0200, Ralf Wildenhues wrote:
> > +	     eval $(SHELL) "\"\$$rootsrc/testsuite/configure\" $$configargs" \
> > +			   "\"--srcdir=\$$rootsrc/testsuite\"" \
> 
> do I miss anything if here would be just such simple quoting?
> 
> 	     eval $(SHELL) $${rootsrc}/testsuite/configure "$$configargs" \
> 			   --srcdir=\$${rootsrc}/testsuite \
> 
> Other parts of Makefile.in already cannot cope with spaces in $srcdir.

True.  The quoting also avoids globbing, though, so I've become used to
using it consistently, also because many other packages do cope with
spaces in the absolute directory name, as long as $srcdir is relative
and doesn't contain any spaces.  But hey, if it's desired, I'll gladly
change the patch as above.

Thanks,
Ralf

Re: obtaining configure args from config.status

[Tom Tromey]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

Ralf> Ping <http://sourceware.org/ml/gdb-patches/2009-08/msg00592.html>

Ok.  Thanks.

Tom

Re: obtaining configure args from config.status

[Tom Tromey]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

>> eval $(SHELL) $${rootsrc}/testsuite/configure "$$configargs" \
>> --srcdir=\$${rootsrc}/testsuite \
>> Other parts of Makefile.in already cannot cope with spaces in $srcdir.

Ralf> True.  The quoting also avoids globbing, though, so I've become used to
Ralf> using it consistently, also because many other packages do cope with
Ralf> spaces in the absolute directory name, as long as $srcdir is relative
Ralf> and doesn't contain any spaces.  But hey, if it's desired, I'll gladly
Ralf> change the patch as above.

If it doesn't hurt anything (other than readability), it is ok to leave
it as you have it.

Tom

Re: obtaining configure args from config.status

[Ralf Wildenhues]

* Tom Tromey wrote on Tue, Sep 08, 2009 at 08:38:11PM CEST:
> >>>>> "Ralf" == Ralf Wildenhues writes:
> 
> >> eval $(SHELL) $${rootsrc}/testsuite/configure "$$configargs" \
> >> --srcdir=\$${rootsrc}/testsuite \
> >> Other parts of Makefile.in already cannot cope with spaces in $srcdir.
> 
> Ralf> True.  The quoting also avoids globbing, though, so I've become used to
> Ralf> using it consistently, also because many other packages do cope with
> Ralf> spaces in the absolute directory name, as long as $srcdir is relative
> Ralf> and doesn't contain any spaces.  But hey, if it's desired, I'll gladly
> Ralf> change the patch as above.
> 
> If it doesn't hurt anything (other than readability), it is ok to leave
> it as you have it.

Yes, it should not hurt.  Thanks for the review, applied.