* Alexandre Duret-Lutz wrote on Wed, May 10, 2006 at 11:54:46PM CEST: > >>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> RW> Do you think it's ok to require that `./file' should not be used? > > This reminds me of a friend who used > AC_CONFIG_FILES([./Makefile ./sub/Makefile]) > and I think it broke something (maybe the rebuild rules). Yes: if Makefile.in is out of date: | cd .. && /bin/sh /tmp/foo/config/missing --run automake-1.9 --foreign ./Makefile | cd . && /bin/sh ./config.status Makefile | config.status: error: invalid argument: Makefile $ config.status --help | grep Make | ./Makefile [...] This rule also extends to stuff like AC_CONFIG_AUX_DIR([./config]) (and macro dir) which I've seen in packages out there. > RW> Should it be documented in automake.texi? > RW> Alternatively, should EXTRA_DIST be rewritten by Automake > RW> to kill leading "./"? > > It's best if we can avoid rewriting anything. > Maybe we could find a way to warn against it (with -Wportability). Good idea. But we'd have to keep in mind that using ./file is good (and may even be necessary) for files created in the build tree. (It may be necessary if those files are ever referenced as prerequisites that way.) > I think ideally Automake should diagnose file names that > are referenced differently in targets and dependencies. Yep. I think just finding this out could be quite expensive though, and running `automake' already is very expensive, sometimes by far the most expensive part of a bootstrap. > I'm currently writing an introductory chapter for the manual > (partly based on my tutorial), and plan to reorganize and add a > few sections that introduce the naming conventions and the > general syntax (the manual doesn't describe the Makefile.am > syntax so far, srcdir isn't even introduced). I hope it will be > easier to explain how and when to use ./, $(srcdir), etc., after > that. Great! > RW> * tests/distdir.test: Do not use leading `./' in EXTRA_DIST for > RW> files in the source tree. Fixes failures with HP-UX and Tru64 > RW> make. > > Agreed. I've applied that; thanks for the review! Cheers, Ralf