Subject: Re: bug#59099: 3-rd party aux files.

From: Karl Berry <[email-masked]>
Date: Sat, 12 Nov 2022 14:26:47 -0700

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.