The problem if the same helper files are shared, i. e. used
in more than one project.
Ack.
thinking about copying existing aclocal behavior:
Interesting and thorough, but I admit aclocal doesn't seem like a good
model to me. aclocal has to do complicated things because it is merging
individual macros into a single file, but what you need is simply a
system-wide directory to store new files, that don't exist
elsewhere. In general, simpler changes are better, for myriad reasons.
Automake already has --libdir/AUTOMAKE_LIBDIR to find library files. So
inventing a whole parallel mechanism seems like it would result in
confusion/clashes. Hence my idea of a new option+envvar
--libdirs/AUTOMAKE_LIBDIRS, essentially extending the automake libdir
into being a path. That still seems like a relatively straightforward
and sufficient solution, as I understand it. Wdyt?
I'm not sure about adding a default directory. /etc/automake comes to
mind, for the reasons you gave about the dirlist file, but I wonder if
distros already use /etc/automake for something or another. I don't know.
4. A directory for third-party system-wide files â to
do. Directory will be, obviously, /usr/share/automake (non-versioned).
/usr/share/automake was used by automake before the invention of
/usr/share/automake-VERSION. I don't know if anyone is still using those
(quite) old automake versions, but could be. Seems too confusing to
reuse it, in any case.
6. Extra directories with "dirlist" â to do.
I wouldn't worry about anything like the dirlist file. There are enough
ways to set the directory.
9. "#serial" comment â to do.
I also don't think there's a need to support a serial comment, because
automake doesn't do any such checking now for files in libdir. They are
just unconditionally used/copied. As far as I know. --best, karl.
