bug#59099: 3-rd party aux files.

[Van de Bugger]

> Interesting and thorough, but I admit aclocal doesn't seem like
> a good model to me.

It could be not the best approach, but definitely good enough, since
(1) it is already exists, and (2) it is already exists in automake
(aclocal is a part of automake).

> aclocal has to do complicated things because it is merging
> individual macros into a single file…

In my eyes the difference is rather small. Both aclocal and automake
look for components in a number of sources and add them to the
projects. Whether it will be a single file aclocal.m4 or few files in
aux directory is a technical detail and does not really matter.

> Automake already has --libdir/AUTOMAKE_LIBDIR to find library
> files. So inventing a whole parallel mechanism seems like it
> would result in confusion/clashes.

W-w-w-wait a minute. I do **not** invent a new **parallel** mechanism,
a want to **extend** **existing** one by **reusing** **another**
**existing** mechanism. 

I did not study aclocal and automake source code, so I do not know how
easy to actually reuse aclocal code in automake; but it seems it is
possible since both tools are written in Perl. In any case, logically I
want reuse aclocal search algorithm in automake, I do not invent
anything new.

> Hence my idea of a new option+envvar --libdirs/AUTOMAKE_LIBDIRS…

Are --libdirs/AUTOMAKE_LIBDIRS exact names? I do not like them, because
you are going to keep --libdir/AUTOMAKE_LIBDIR for backward
compatibility. --libdir is too similar to --libdirs: one letter
difference in spelling, but the difference in behavior is striking. It
will be too easy to make a mistake.

> /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.

Even so, I do not think it is an issue. Up to now, there is no 3-rd
party aux files. Automake documentation can list all existing aux files
(only 14 files) and indicate that these names are reserved. Future
automake aux files can be prefixed with am- or am_ to avoid clashes
with third-party aux files.

> I wouldn't worry about anything like the dirlist file. There
> are enough ways to set the directory.

dirlist file is documented, and documentations provide quite good
reasoning for it. In case of copying aclocal searching algorithm, I see
no reason to exclude dirlist.

> 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.

Up to now, all the aux files are coming from the same source — they are
provided by automake, so there is no need in versioning. But allowing
third-party aux files changes it.

Also, in case of copying aclocal searching algorithm, I see no reason
to exclude file versioning.