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

[Ralf Wildenhues]

* 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