bug#59099: 3-rd party aux files.

2. find_file
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 pre=
fer
to rename the original function to find_file_m4, since it is more specializ=
ed,
while find_file_with_opt is more generic.


2a. find_file description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Look, the last argument *was* described:

=3Ditem C<find_file ($file_name, @include, {optional =3D> $bool})>

...

find_file ($FILE_NAME, @INCLUDE, {optional =3D> $BOOL})
--------------------------------

Do you think it is not obvious enough?


3. Disclaimer
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I have sent the request. Will they send back an electronic form, or will it=
 be
a paper sent via ground mail?


1. --libdir option
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

It is the most complicated item.

Original behaviour
------------------

1.  Search in the dir specified by the --libdir option, if the option is gi=
ven.
2.  If --libdir is not given, search in the dir specified by the=20
    AUTOMAKE_LIBDIR env var, if the var exists.
3.  If --libdir is not given and the AUTOMAKE_LIBDIR var does not exist, se=
arch=20
    in the default directory @datadir@/@PACKAGE@-@APIVERSION@.

Note: The search for a file is performen only in the first specified direct=
ory,
searching never continues in the next directory.

If someone wants to specify custom directory with AUTOMAKE_LIBDIR or --libd=
ir,
he must provide the entire Automake library (ar-lib, compile, config.guess,
etc, including all files in the am/ subdirectory!), otherwise Automake will
likely fail. All this stuff is obviously not designed for end-user use.

So, I'm guessing that --libdir and AUTOMAKE_LIBDIR are only used by Automak=
e
itself, and only for testing purposes. Can you come up with any case, where=
 a
user would use AUTOMAKE_LIBDIR or --libdir?

Proposed behavior
-----------------

Search path:

1.  Directories specified by --libdir options, in order of appearance (but =
see=20
    below).
2.  Dirtectory specified by AUTOMAKE_LIBDIR environment variable.
3.  Directories specified by AUTOMAKE_LIBDIRS environment variable.
4.  Standard directories (one unversioned and one versioned).

Note: If a file is not found in one directory, searching continues in the n=
ext
directory.

This behavior is very compatible with the old behavior: first search in
--libdir directory, if the option is not specified, search in the directory
specified by AUTOMAKE_LIBDIR variable, if the variable is not specified, se=
arch
in the standard directory. I see only two potential issues:

1.  The search continues in the next directory if the requested file is not=
=20
    found.
2.  The next --libdir option does not override the previous.

I believe the first issue is not one we should worry about: If the user
specifies a custom library directory for the old Automake, he must provide =
the
entire Automake library, otherwise Automake will fail. So, if Automake work=
s,
it means all the files are in the first directory, and search continuation =
will
not occur. Well, the new Automake will work in some cases where the old
Automake does not work: if the user does not provide the entire Automake
library in the custom libdir directory. Do you think this is a problem?

The second issue, multiple --libdir options, is also a corner case. Who wou=
ld
specify multiple --libdir options, and why?

By the way, the second issue can be easily fixed by adding directories to t=
he
beginning of the include list, so the next --libdir option takes precedence
over the previous one. (It is not like gcc handles -I options, but in any c=
ase
it is easy to understand and trivial to implement.)

If you disagree with this approach, could you please describe you vision in
more details? Adding an option --add-libdir is not a problem, but how shoul=
d it
interfere with existing option --libdir and environment variable(s)?



On Thu, 2025-04-10 at 16:47 -0600, Karl Berry wrote:
> Thanks for the patch, and sorry for the delayed reply. My concerns are:
>=20
> 1. Changing the meaning of the --libdir option so that it adds rather =
=20
> than replaces. We have no way of knowing if existing projects rely on =
=20
> that, but it's quite possible. A new option name is needed to avoid =20
> breaking compatibility. Since you don't like --libdirs (neither do I), =
=20
> maybe --add-libdir. (The new --print-libdir[s] is ok, since that won't =
=20
> change existing behavior, i.e., if the new "libdir list" functionality =
=20
> is not used, the output will be the same. As I understand it.)
>=20
> 2. Although Automake does not use the find_file function, autom4te (in =
=20
> autoconf) does. Right now the Automake and Autom4te FileUtils.pm are =20
> kept in sync (by make fetch in autoconf), as far as I can see. Thus we =
=20
> cannot change the behavior of find_file. Instead, a new function name is =
=20
> needed, e.g., find_file_no_cwd or find_file_with_opt.
>=20
> 2a. Also, the new description in the FileUtils.pm change does not =20
> mention the new final argument, or what the possible options can be.=C2=
=A0 (I =20
> can tell from the code, I think, but it should be in the comment for the =
=20
> function.)
>=20
> 3. In order to install any patch, I need to ask you to sign a copyright =
=20
> disclaimer or assignment. I hope that's ok. I'll send you that form =20
> separately.
>=20
> Thanks again, =20
> Karl