2. find_file
No problem. I renamed find_file to find_file_with_opt and brought back the
original find_file (with new implementation, thought). Frankly, I would prefer
to rename the original function to find_file_m4, since it is more specialized,
while find_file_with_opt is more generi
Hi,
> Since the purpose of the new feature is to support per-project helper
> files (right?)…
No exactly. Per-project helper files can be easily added to the project
source with no problem. The problem if several projects share the same
helper files. Currently such files should be managed manuall
> 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 b
> Since the purpose of the new feature is to support per-project helper
> files (right?), a single system directory doesn't seem right. Let's
> not mess around with system directories if we can help it.
Not exactly. Truly per-project helper files is *not* a problem — they
can be stored in the pro
> If you, or anyone, can draft a patch, that would be great.
I think I could draft a patch, but I am not sure which interface to
choose for the new feature. I see few possible approaches:
1. Let automake look for aux files in *two* directories:
/usr/share/automake-1.16 and /usr/share/automake. I
Software versions
=
* Fedora 29, x86_64
* autoconf-2.69-28.fc29.noarch
* automake-1.16.1-5.fc29.noarch
Steps to reproduce
==
$ tar xaf distdir.patch.tar.gz
$ cd distdir.patch
$ mkdir _build
$ cd _build
$ autoreconf -i ..
$ ../configu
