>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> 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
