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

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> In the long run, I suppose that AC_LIBOBJ and AC_LIBSOURCES
>> might be adjusted to search for required files in multiple directories.
>> Or maybe each could have an optional argument specifying the directory
>> to search.
>
> But then, the copy of hard-locale.m4 for coreutils would have to be
> different from the copy of hard-locale.m4 for gettext. Then we get even
> deeper in the pit, by not only putting filenames but also directory
> names into the .m4 files.

Ok.  Then consider the former suggestion.  Maybe packages like
gettext would add a directive somewhere specifying that automake
search also in another directory.

...
> Thanks. But this shows that
>
>   1) Your declared goal of eliminating the filenames of the Makefile.am
>      is not fulfilled: they come back, in the form of PHONY rules.

But only for unusual packages, like gettext.  Do you know
of any others like it?

For the vast majority of packages, it does accomplish my stated
goal (perhaps you didn't read the whole thread?) of *increased*
*robustness* in the tighter coupling between .m4 files and
their required source files.  [my stated goal was *not* simply
to avoid listing source file names in Makefile.am]

>   2) It requires an automake wizard to survive in this situation.

But only once.  Now that you know the work-around,
you don't have to look through the source.

>> > Bottom line: The AC_LIBSOURCES approach causes unnecessary hassles.
>>
>> You should qualify that:  it requires a small work-around
>> for packages like gettext that split gnulib sources.
>
> It requires hacks in all directions. Whereas the current solution, to
> put filenames into Makefile.am _works_ and is _robust_.

``hacks in all directions''?  That sounds disingenuous.

It requires a single work-around, and that only to accommodate
one irregular package: gettext.  The current approach
(weak-to-no coupling) usually works but is not robust.  Perhaps
you forgot the scenario that provoked this?  Someone writes or
uses a new .m4 macro and adds that file but forgets to add the
names of one or more of the source files to lib/Makefile.am.
They discover the error only after a major release, since it
affects only a few, unusual systems.

> *What* is the problem with filenames in Makefile.am that you are fighting
> against?

I am addressing the problem of the current long-distance
(hence loose and fragile) dependency of .m4 files upon their
required source (e.g., .[chy]) files.  In the absence of the
tighter coupling provided by the added uses of AC_LIBSOURCES
and AC_LIBOBJ, it is far too easy to forget to include a .c or
.h file in Makefile.am.