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 generic.
2a. find_file description
=========================
Look, the last argument *was* described:
=item C<find_file ($file_name, @include, {optional => $bool})>
...
find_file ($FILE_NAME, @INCLUDE, {optional => $BOOL})
--------------------------------
Do you think it is not obvious enough?
3. Disclaimer
=============
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
==================
It is the most complicated item.
Original behaviour
------------------
1. Search in the dir specified by the --libdir option, if the option is given.
2. If --libdir is not given, search in the dir specified by the
AUTOMAKE_LIBDIR env var, if the var exists.
3. If --libdir is not given and the AUTOMAKE_LIBDIR var does not exist, search
in the default directory @datadir@/@PACKAGE@-@APIVERSION@.
Note: The search for a file is performen only in the first specified directory,
searching never continues in the next directory.
If someone wants to specify custom directory with AUTOMAKE_LIBDIR or --libdir,
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 Automake
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
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 next
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, search
in the standard directory. I see only two potential issues:
1. The search continues in the next directory if the requested file is not
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 works,
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 would
specify multiple --libdir options, and why?
By the way, the second issue can be easily fixed by adding directories to the
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 case
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 should 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:
>
> 1. Changing the meaning of the --libdir option so that it adds rather
> than replaces. We have no way of knowing if existing projects rely on
> that, but it's quite possible. A new option name is needed to avoid
> breaking compatibility. Since you don't like --libdirs (neither do I),
> maybe --add-libdir. (The new --print-libdir[s] is ok, since that won't
> change existing behavior, i.e., if the new "libdir list" functionality
> is not used, the output will be the same. As I understand it.)
>
> 2. Although Automake does not use the find_file function, autom4te (in
> autoconf) does. Right now the Automake and Autom4te FileUtils.pm are
> kept in sync (by make fetch in autoconf), as far as I can see. Thus we
> cannot change the behavior of find_file. Instead, a new function name is
> needed, e.g., find_file_no_cwd or find_file_with_opt.
>
> 2a. Also, the new description in the FileUtils.pm change does not
> mention the new final argument, or what the possible options can be. (I
> can tell from the code, I think, but it should be in the comment for the
> function.)
>
> 3. In order to install any patch, I need to ask you to sign a copyright
> disclaimer or assignment. I hope that's ok. I'll send you that form
> separately.
>
> Thanks again,
> Karl
