Ralf Wildenhues wrote:
> Speaking of short-sighted is a bit stretched
That word is withdrawn.
> with some functionality that basically serves for more than half a decade.
The functionality that can be triggered through Makefile.am variables is
indeed well designed and rock solid. Kudos especially to Alexandre who
added so many tests. But it took me a lot of experience with gnulib-tool
to understand that, unfortunately, the {AC_LIBSOURCES, AC_LIBOBJ,
AC_CONFIG_LIBOBJ_DIR} combo of functionality is not on the same level of
dependability.
Apologies if someone feels hurt.
> You could simplify this further:
> - header files can go into *_SOURCES variables since about a decade now,
> - EXTRA_*_SOURCES are already distributed.
>
> That means you can drop most EXTRA_DIST settings.
Doing so wouldn't make gnulib-tool simpler or more reliable. What's the
point of ensuring that *_SOURCES and EXTRA_DIST are disjoint? For human
maintainers, it's that it's less to type. But when it's automatically
generated?
Btw, I don't know what happens if I add .m4 or .java files to *_SOURCES.
Automake might want to activate its own Java compilation rules...
> coreutils now still needs one more fix, after Jim's:
> some of its own lib files are still not dependency-tracked:
> | ls: .deps/fdopendir-glibc.Po: No such file or directory
> | ls: .deps/lstat-stub.Po: No such file or directory
> | ls: .deps/readlink-stub.Po: No such file or directory
> | ls: .deps/stdopen.Po: No such file or directory
>
> Or is it that these files are never needed?
stdopen is unused, and is not mentioned in any Makefile.am nor configure.ac.
Bruno
