* Alexandre Duret-Lutz wrote on Mon, Jul 16, 2007 at 10:45:52PM CEST: > >>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> 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
