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.