Re: [bug-gnulib] FYI: adding AC_LIBSOURCES/AC_LIBOBJ in coreutils .m4 files

[Alexandre Duret-Lutz]

>>> "Jim" == Jim Meyering <address@hidden> writes:

[...]

 Jim> As I thought you, as Mr. Automake :) might want to comment
 Jim> on my suggestion that automake might someday look in more
 Jim> than one directory for files required by AC_LIBSOURCES/AC_LIBOBJ.

I'm puzzled by this suggestion, probably I'm still missing
something.

AC_LIBSOURCE[S] is used to declare source files that are needed
to build @address@hidden  If @LIBOBJS@ is used in one directory, all
its sources files must be there too.  Why would someone want to
scatter the sources file of objects that are built in the same
directory?

I assume the latter sentence does not describe the Gettext
package, hence my puzzlement.

If some more complex machinery is needed here (for instance
generalize AC_LIBSOURCE/AC_LIBOBJ to more than one @LIBOBJS@
variable), I think it needs be done in both Autoconf and
Automake properly.

[...]

 Jim> I provided a work-around for the gettext-related problem Bruno reported.

I confess I don't understand how this works.  Does it really pass
`make dist'?  I'd find this surprising: one reason Automake
requires these files is so it can distribute them.  

Some packages do generate distributed files like README from
other sources.  Therefore Automake does not warn if such a file
is missing but a rule exists, because that file will be
generated to first time the maintainer run `make dist'.

 Jim> [I've forwarded to Alexandre a copy of the earlier message. ]


>>> "Bruno" == Bruno Haible <address@hidden> writes:

[...]

 Bruno> Are you saying that all packages should have the same
 Bruno> directory layout as coreutils, namely one src/ and one
 Bruno> lib/ directory?

I think the message is that all gnulib modules should be in the
same directory.  That seems wise to me.  They are third-party
sources anyway, it helps to keep the logic of the package
understandable by other people (e.g. I still do not really
understand how Gettext interacts with gnulib), it free you
from some maintenance (a single Makefile.am, no hacks), and
it keeps the tools simple.

[...]

 Bruno> ? Move the whole contents of libuniname and libgrep into lib/ and
 Bruno> merge the three Makefile.am's.
 Bruno> - I refuse to do so, because as mentioned above, this would be
 Bruno> the tool dictating the directory structure to the maintainer.

That's a very human feeling.  People don't like to do what they
are forced to.  But if that is the only objection, maybe you can
get over it.

I see value in having GNU packages follow a similar layout when
possible (and it seems to be possible here).  For instance it is
nice for translators to have a po/ directory in all packages.
It would be horrible if every maintainer chose its own name and
place for that directory.

 Bruno> Also I don't like directories to contain unrelated parts.

Consider 'gnulib modules' to be the common denominator that
relates all parts?

 Bruno> ? Move the hard-locale, regex, strdup modules from libgrep/ to lib/.
 Bruno> - This would increase the size of the shared library, and thus
 Bruno> increase the startup time of all programs, just for the sake
 Bruno> of a single program.

That would have been my suggestion.  How many symbols are we
talking about?  (I for one wouldn't waste maintenance time
splitting libraries this way if that concerns just a handful of
symbols.)
-- 
Alexandre Duret-Lutz