Re: "Deleted header file" problem: aclocal.m4 deps

[Alexandre Duret-Lutz]

>>> "RW" == Ralf Wildenhues <address@hidden> writes:

[...]

 RW> Index: lib/am/configure.am
 RW> ===================================================================
 RW> RCS file: /cvs/automake/automake/lib/am/configure.am,v
 RW> retrieving revision 1.31
 RW> diff -u -r1.31 configure.am
 RW> --- lib/am/configure.am    14 May 2005 20:28:52 -0000      1.31
 RW> +++ lib/am/configure.am    17 Sep 2006 18:10:56 -0000
 RW> @@ -113,7 +113,10 @@
 RW> ## aclocal.m4 too.  Changing configure.ac, or any file included by
 RW> ## aclocal.m4 might require adding more files to aclocal.m4.  Hence
 RW> ## the $(am__configure_deps) dependency.
 RW> +##
 RW> +## Avoid the "deleted header file" problem for the dependencies.
 RW> if %?REGEN-ACLOCAL-M4%
 RW> +$(am__aclocal_m4_deps):
 RW> $(ACLOCAL_M4): %MAINTAINER-MODE% $(am__aclocal_m4_deps)
 RW> ?TOPDIR_P? cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
 RW> ?!TOPDIR_P?        cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) 
am--refresh

Would it be possible to rearrange the comments here?  It looks
like you inserted your comment/code between in the middle of
a comments/code pair.

 RW> +# Make sure the "deleted header file" issue is fixed wrt. aclocal.m4
 RW> +# dependencies.
 RW> +
 RW> +. ./defs || exit 1
 RW> +
 RW> +set -e
 RW> +
 RW> +cat >>configure.in <<EOF
 RW> +FOO
 RW> +AC_OUTPUT
 RW> +EOF
 RW> +cat >foo.m4 <<EOF
 RW> +AC_DEFUN([FOO], [:])
 RW> +EOF
 RW> +: >Makefile.am
 RW> +$ACLOCAL -I .
 RW> +$AUTOMAKE
 RW> +$AUTOCONF
 RW> +./configure
 RW> +$MAKE
 RW> +sed '/FOO/d' < configure.in > t
 RW> +mv -f t configure.in
 RW> +rm -f foo.m4
 RW> +$MAKE

I'm not convinced by this test: what proof do I have that this
last $MAKE is doing The Right Thing?

How about something along the lines of (not tested) :

cat >>configure.in <<EOF
FOO
AC_OUTPUT
EOF
cat >foo.m4 <<EOF
AC_SUBST([GREPFOO])
EOF
cat >bar.m4 <<EOF
AC_SUBST([GREPBAR])
EOF
echo 'ACLOCAL_AMFLAGS = -I .'  >Makefile.am
$ACLOCAL -I .
$AUTOMAKE
$AUTOCONF
./configure
$MAKE
grep GREPFOO Makefile
grep GREPBAR Makefile || exit 1
sed '/FOO/d' < configure.in > t
mv -f t configure.in
rm -f foo.m4
$MAKE
grep GREPFOO Makefile || exit 1
grep GREPBAR Makefile

 RW> I can see two possible counterarguments, which is why I would be
 RW> grateful if Alexandre could comment:

 RW> - this way, you won't notice if you accidentally deleted the file (say,
 RW> because there exists an installed version that provides the macro).
 RW> The analogy wrt. installed C/C++ header files only goes so far:
 RW> distributed uninstalled header files that never have an installed
 RW> equivalent are very common and provoke a failure from the
 RW> preprocessor.
 RW> - I'm not totally sure automake won't be able to (mis)interpret the
 RW> added line at some point in the future (or now, FWIW).

 RW> If those issues aren't a big problem, then I'd all be for putting this
 RW> into HEAD (including a NEWS entry).  I mean, that's why I wrote the
 RW> patch in the first place.  ;-)

These don't look like problems to me.

On a slightly different topic, but related to these
"dependency-less" targets, I've been wondering several times
whether it would be correct to add such a rule for the
.deps/*.P* files.  I'm thinking of something like

./$(DEPDIR)/foo.Plo ./$(DEPDIR)/bar.Plo ./$(DEPDIR)/baz.Plo ...:
        @echo '# dummy' > $@

Although I'm not sure when this happens, occasionally some
.deps/*.P* files get lost, make complains, and it's not obvious
to users they have to run ./config.status to get them back.  

GNU make will rebuild a missing `include'd file for which there
exist a rule, but BSD make will not.  That means the above rule
would just be an help to users of GNU make, not a replacement
for the ugly AM_OUTPUT_DEPENDENCY_COMMANDS.  (I which there was
a way to get rid of AM_OUTPUT_DEPENDENCY_COMMANDS!)

Someone once suggested using "-include" instead of "include",
when available.  I would see that as complementary.
-- 
Alexandre Duret-Lutz

Shared books are happy books.     http://www.bookcrossing.com/friend/gadl