Re: [bug-gnulib] Redundant AC_LIBSOURCES calls
Hello, On Fri, Sep 23, 2005 at 02:37:06PM +0200, Bruno Haible wrote: > Stepan Kasal wrote: > > But in the basic case, when only the implementation is fixed and no > > header is needed, I see no advantage in adding a redundant call to > > AC_LIBSOURCES. > > The advantage is simplicity and consistency. I thought you would object... ;-) It's only a matter of style and preferrence, no big deal. > Your approach is even worse: It forces the maintainer to look or grep > for AC_LIBOBJ invocations in the autoconf macros. And not only in the > package's *.m4 files, but also in autoconf's and automake's own *.m4 files! > It opens the door to problems that will appear with one version of autoconf > and not with another... > > Too much magic -> implies -> too much complexity when debugging. The magic is already there: AC_LIBOBJ calls AC_LIBSOURCE since 2.50 when it was introduced. I don't see any chance to remove it now. This magic can complicate debugging, yes. Even though gnulib uses the redundant style, the magic is still hidden behind, ready to bite you! OK, forget about it. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] Redundant AC_LIBSOURCES calls
Stepan Kasal wrote: > But in the basic case, when only the implementation is fixed and no > header is needed, I see no advantage in adding a redundant call to > AC_LIBSOURCES. The advantage is simplicity and consistency. In an ideal world, all source files are listed in Makefile.am. Very simple, consistent, and makes it very easy to debug problems that might appear with "make dist". The approach to use AC_LIBSOURCES for all source files, is already worse because - it mixes autoconfiguration issues and pathname issues, - it assumes a transfer of information from a *.m4 file to a *.am file which automake does not implement in with sufficient generality. But at least, it can be consistent, and if every gnulib module has a .m4 file with AC_LIBSOURCES invocations for all source files, you know where to look when problems appear during "make dist". Your approach is even worse: It forces the maintainer to look or grep for AC_LIBOBJ invocations in the autoconf macros. And not only in the package's *.m4 files, but also in autoconf's and automake's own *.m4 files! It opens the door to problems that will appear with one version of autoconf and not with another... Too much magic -> implies -> too much complexity when debugging. Keep it simple! Even if some things are then redundant. Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
