Redundant AC_LIBSOURCES calls

2005-09-23 Thread Stepan Kasal
Hello,

I propose the patch attached below; an explanation follows:

I think that when AC_LIBOBJ and friends was designed, the idea was
to use
some testing
if foo_is_broken; then
AC_LIBOBJ([foo])
fi

The AC_LISOURCE/AC_LIBSOURCES macros were also made visible, so that
the user can name additional sources, when necessary.

Actually, gnulib needs foo.h in most cases, because the module fixes
also a broken declaration, not only broken implementation.

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.

Have a nice day,
Stepan Kasal
2005-09-23  Stepan Kasal  <[EMAIL PROTECTED]>

* m4/gettime.m4, m4/getugroups.m4, m4/idcache.m4, m4/inttostr.m4,
  m4/nanosleep.m4, m4/settime.m4: Remove redundant AC_LIBSOURCES.

Index: m4/gettime.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/gettime.m4,v
retrieving revision 1.4
diff -u -r1.4 gettime.m4
--- m4/gettime.m4   26 Feb 2005 08:18:27 -  1.4
+++ m4/gettime.m4   23 Sep 2005 09:57:45 -
@@ -6,7 +6,6 @@
 
 AC_DEFUN([gl_GETTIME],
 [
-  AC_LIBSOURCES([gettime.c])
   AC_LIBOBJ([gettime])
 
   dnl Prerequisites of lib/gettime.c.
Index: m4/getugroups.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/getugroups.m4,v
retrieving revision 1.4
diff -u -r1.4 getugroups.m4
--- m4/getugroups.m421 Mar 2005 22:06:27 -  1.4
+++ m4/getugroups.m423 Sep 2005 09:57:45 -
@@ -6,7 +6,6 @@
 
 AC_DEFUN([gl_GETUGROUPS],
 [
-  AC_LIBSOURCES([getugroups.c])
   AC_LIBOBJ([getugroups])
 
   dnl Prerequisites of lib/getugroups.c.
Index: m4/idcache.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/idcache.m4,v
retrieving revision 1.4
diff -u -r1.4 idcache.m4
--- m4/idcache.m4   21 Mar 2005 22:06:27 -  1.4
+++ m4/idcache.m4   23 Sep 2005 09:57:45 -
@@ -6,7 +6,6 @@
 
 AC_DEFUN([gl_IDCACHE],
 [
-  AC_LIBSOURCES([idcache.c])
   AC_LIBOBJ([idcache])
 
   dnl Prerequisites of lib/idcache.c.
Index: m4/inttostr.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/inttostr.m4,v
retrieving revision 1.4
diff -u -r1.4 inttostr.m4
--- m4/inttostr.m4  21 Mar 2005 22:06:27 -  1.4
+++ m4/inttostr.m4  23 Sep 2005 09:57:45 -
@@ -8,11 +8,6 @@
 [
   AC_LIBSOURCES([inttostr.c, inttostr.h, intprops.h])
 
-  dnl We don't technically need to list the following .c files, since their
-  dnl functions are named in the AC_LIBOBJ calls, but this is an unusual
-  dnl module and it seems a little clearer to do so.
-  AC_LIBSOURCES([imaxtostr.c, offtostr.c, umaxtostr.c])
-
   AC_LIBOBJ([imaxtostr])
   AC_LIBOBJ([offtostr])
   AC_LIBOBJ([umaxtostr])
Index: m4/nanosleep.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/nanosleep.m4,v
retrieving revision 1.20
diff -u -r1.20 nanosleep.m4
--- m4/nanosleep.m4 2 May 2005 07:00:50 -   1.20
+++ m4/nanosleep.m4 23 Sep 2005 09:57:45 -
@@ -12,8 +12,6 @@
 
 AC_DEFUN([gl_FUNC_NANOSLEEP],
 [
- AC_LIBSOURCES([nanosleep.c])
-
  nanosleep_save_libs=$LIBS
 
  # Solaris 2.5.1 needs -lposix4 to get the nanosleep function.
Index: m4/settime.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/settime.m4,v
retrieving revision 1.4
diff -u -r1.4 settime.m4
--- m4/settime.m4   21 Mar 2005 22:06:27 -  1.4
+++ m4/settime.m4   23 Sep 2005 09:57:45 -
@@ -6,7 +6,6 @@
 
 AC_DEFUN([gl_SETTIME],
 [
-  AC_LIBSOURCES([settime.c])
   AC_LIBOBJ([settime])
 
   dnl Prerequisites of lib/settime.c.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: [bug-gnulib] Redundant AC_LIBSOURCES calls

2005-09-23 Thread Bruno Haible
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


Re: [bug-gnulib] Redundant AC_LIBSOURCES calls

2005-09-23 Thread Stepan Kasal
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