[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Deleted header file" problem: aclocal.m4 deps
From: |
Ralf Wildenhues |
Subject: |
Re: "Deleted header file" problem: aclocal.m4 deps |
Date: |
Tue, 17 Jul 2007 00:23:31 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
* Alexandre Duret-Lutz wrote on Mon, Jul 16, 2007 at 10:45:52PM CEST:
> >>> "RW" == Ralf Wildenhues <address@hidden> writes:
>
[...]
> 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?
Hmm. You may not have.
> How about something along the lines of (not tested) :
>
> cat >>configure.in <<EOF
> FOO
> AC_OUTPUT
> EOF
> cat >foo.m4 <<EOF
> AC_SUBST([GREPFOO])
Do you mean
AC_DEFUN([FOO], [AC_SUBST([GREPFOO])])
here?
> EOF
> cat >bar.m4 <<EOF
> AC_SUBST([GREPBAR])
I'm sorry but I'm unable to infer what you meant here,
or what you're trying to test by use of bar.m4.
> EOF
> echo 'ACLOCAL_AMFLAGS = -I .' >Makefile.am
> $ACLOCAL -I .
> $AUTOMAKE
> $AUTOCONF
> ./configure
> $MAKE
> grep GREPFOO Makefile
> grep GREPBAR Makefile || exit 1
`&&' instead of `||'?
> sed '/FOO/d' < configure.in > t
> mv -f t configure.in
> rm -f foo.m4
> $MAKE
> grep GREPFOO Makefile || exit 1
Likewise.
> grep GREPBAR Makefile
I can redo the patch if you like, given above.
> RW> I can see two possible counterarguments, which is why I would be
> RW> grateful if Alexandre could comment:
[...]
>
> These don't look like problems to me.
OK good.
> 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.
Well, wouldn't it be better to find out the cause of them being lost?
Of course, some users like to 'rm -rf' subtrees, which is a probable
cause. Non-recursive make makes cleaning of subtrees a bit harder.
> 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.
So that's not really a good help then, but will cause action to differ
even more.
> (I which there was
> a way to get rid of AM_OUTPUT_DEPENDENCY_COMMANDS!)
I should point out that I've been working on this macro, on and off.
Without a final result, but with some crazy ideas at least:
<http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/3885/focus=3893>
<http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2363/focus=2766>
> Someone once suggested using "-include" instead of "include",
> when available. I would see that as complementary.
Was it not that there was no portable "-include" among 'make'
implementations? (I don't remember well, but I do remember that
there was a mildly compelling reason against it.)
Cheers,
Ralf