I renamed find_file to find_file_with_opt
Thanks.
I would prefer to rename the original function to find_file_m4
I agree in the abstract, but it's not worth creating an incompatibility.
Look, the last argument *was* described:
Yes, I saw that, but a few words in the description would only help,
since it's easy to get confused about "optional" being a key name.
I can take care of it when I eventually commit this.
I have sent the request. Will they send back an electronic form, or
will it be a paper sent via ground mail?
As far as I know, the assignment process is entirely electronic nowadays.
That is, I believe they'll accept paper if you prefer that, but
otherwise a gpg-signed file suffices.
1. The search continues in the next directory if the requested file
is not found.
...
I believe the first issue is not one we should worry about:
Your argument on that front is persuasive. I'm willing to give it a try.
The second issue, multiple --libdir options, is also a corner
case. Who would specify multiple --libdir options, and why?
One libdir option could be specified at one level of the build system,
and then a second option at another level. There's no way to know
what distros/packagers/maintainers/etc. have done.
I agree it's an obscure corner case. However, in general, my experience
is that the tiniest change in Automake behavior will break someone's
build. I prefer not to do that if there is a reasonable alternative.
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.
Hmm. Interesting idea for the simplicity of it, but I fear it seems
problematic to me from a user perspective. That is, for people who want
to use the new behavior. The near-universal expectation is that the
first directory given is searched first, like, as you say, -I options to
the compiler.
Adding an option --add-libdir is not a problem, but how should it
interfere with existing option --libdir and environment variable(s)?
My idea is to have one scalar variable $libdir and one list variable
@libdirs.
1a) $libdir is initialized from $ENV{"AUTOMAKE_LIBDIR"}.
1b) --libdir assigns to $libdir, so a second --libdir overwrites the first.
2a) @libdirs is initialized from $ENV{"AUTOMAKE_LIBDIRS"}.
2b) --add-libdir pushes onto @libdirs.
After argument parsing is done, $libdir is pushed to the end of
@libdirs. Then the dirlist and standard directories are
pushed to @libdirs. Then @libdirs is searched.
Or maybe $libdir should be placed at the front of
@libdirs. I admit I'm not sure. My theory is that since no one can be
currently using the new feature, if someone takes the trouble to use it,
they probably want those new dirs to come first.
Wdyt?
4. Standard directories (one unversioned and one versioned).
BTW, the unversioned <prefix>/share/automake was used as the system
directory in early versions of Automake. That was long enough ago (20+
years) that I guess we can resurrect it now as you propose.
Also, not mentioned before: It would be extremely helpful if you could
also include a patch for the documentation to update it for the new
behavior (whatever we decide it is :).
Sorry to be such a pain about all this. You might well be right that
it's unnecessary to go to such lengths. And yet, I feel compatibility
is paramount with Automake. --thanks, karl.
