Package: automake;
Reported by: Van de Bugger <van.de.bugger <at> yandex.ru>
Date: Mon, 7 Nov 2022 08:26:02 UTC
Severity: wishlist
Message #27 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Van de Bugger <van.de.bugger <at> ya.ru> To: Karl Berry <karl <at> freefriends.org> Cc: bug-automake <at> gnu.org Subject: Re: bug#59099: 3-rd party aux files. Date: Sat, 01 Mar 2025 20:06:21 +0300
[Message part 1 (text/plain, inline)]
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 manually: if a helper file changed in one project, it should be manually copied to other projects that use the same helper file. My idea is put all helper files I use in my projects to a library. Every project pulls required files from the library to the project aux directory by running $ autoreconf -i > What comes to mind follows your typo above :) That wasn't a typo. I was going to introduce AUTOMAKE_LIBDIRS environment variable. ⁂ Okay, my initial patch for automake 1.16.5 is attached. Patched automake looks for files in: 1. Directory specified by --libdir option. If more than one --libdir option is present in the command line, directories are searched in left-to-right order. 2. Directory specified by AUTOMAKE_LIBDIR environment variable. 3. Directories specified by AUTOMAKE_LIBDIRS environment variable. The variable contains a list of directories separated with colon (semicolon in case of Windows OS). 4. System directories $datadir/$PACKAGE and $datadir/$PACKAGE- $APIVERSION. ⁂ Implementation details: Instead of $libdir variable containing a single library directory, @libdir array is maintained. Unused FileUtils::find_file function is modified: (1) The current directory is not searched implicitly; (2) File optionality is specified by the last argument, not by question sign in the end of the file name. find_file is used for file search. Arguments of --libdir options are pushed to the @libdirs. When command line parsing finished, content of environment variables AUTOMAKE_LIBDIR and AUTOMAKE_LIBDIRS is appended, as well as the system directories (however, system directories are not appended if automake is not installed). These actions are performed in finalize_libdirs function, because the function is called twice. --print-libdir option is renamed to --print-libdirs. The colon- separated (semicolon in case of Windows OS) list of directories is printed. Old option, --print-libdir, is still recognized as abbreviation of the full name. ⁂ I built the patched automake in Fedora Copr (I have used official Fedora rpm spec and added my patch). Build result is: https://copr.fedorainfracloud.org/coprs/vandebugger/testing/build/8714811/ https://download.copr.fedorainfracloud.org/results/vandebugger/testing/fedora-41-x86_64/08714811-automake/builder-live.log.gz Testsuite summary: # TOTAL: 2980 # PASS: 2882 # SKIP: 60 # XFAIL: 38 # FAIL: 0 # XPASS: 0 # ERROR: 0 You see, all the tests passed. ⁂ Incompatibilities with the previous implementation are minor: 1. Subsequent --libdir option does not override the previous --libdir option. 2. --print-libdir option prints list of directories, not a single directory. ⁂ The patched automake solves my problem. Now I can put all the helper scripts to a directory, set AUTOMAKE_LIBDIRS, and put few lines to autoconf.ac: AC_REQUIRE_AUX_FILE([clean-dir.sh]) AC_REQUIRE_AUX_FILE([check-doc-hunspell.sh]) AC_REQUIRE_AUX_FILE([check-html-tidy.sh]) ... --- On Mon, 2022-11-07 at 16:37 -0700, Karl Berry wrote: > Hi Van - first, I've copied your messages to the bug tracker, so please > use [bug-automake <at> gnu.org](mailto:bug-automake <at> gnu.org) and the given subject line so things stay in > the bug going forward. > [https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59099](https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59099) > (Except my resend of your reply didn't get attached. I don't know why > not. Will try to figure that out. For the record, your msg is here: > [https://lists.gnu.org/archive/html/automake/2022-11/msg00001.html](https://lists.gnu.org/archive/html/automake/2022-11/msg00001.html) > ) > > I am not sure which interface to choose for the new feature. I see > few possible approaches: > > Your summary is admirable :). I think we should have Jim and/or other > more experienced Automakers weigh in before you start coding. But here > are my comments. > > Disadvantage is that both directories are > not writable by non-privileged user. > > 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. > > 2. Let automake maintain the *list* of directories to be searched for > aux files. > > Sounds right. > > In such case, the --libdir option (and the AUTOMAKE_LIBDIRS > environment variable) will insert the given directory to the beginning > (or to the end?) of the list. Multiple --libdir options are allowed. > > I like the idea in general. > > Is there any existing code relying on the fact that automake ignores > standard directory if the --libdir option is specified? > > The answer to the question "does anything depend on X", for any Automake > (or Autoconf) behavior X, is yes. So I think we must not change > existing behavior of --libdir or AUTOMAKE_LIBDIR. Instead, we can add to it. > > What comes to mind follows your typo above :) ... have a new > option/envvar --libdirs/AUTOMAKE_LIBDIRS which maintains an independent > list of directories to search. I think the new dirs should be searched > after the libdir/AUTOMAKE_LIBDIR directory. > > I think the list of dirs should be searched in the order specified: > --libdirs foo --libdirs bar would search foo then bar. > > As with --libdir/AUTOMAKE_LIBDIR, if --libdirs is specified, it would > override (completely) AUTOMAKE_LIBDIRS. No such "extra" directories > would be searched by default. > > Does that reasonably solve your original request? > > Also, it is not clear to me, should it affect searching for *.am > files or not. > > For consistency, I think the new searching should look for the same > files as the existing searching. Presumably that will be > easiest/cleanest to implement, too. > > In general, the closer the new behavior is to the existing, the easier I > think it will be to understand (and implement and document). > > Wdyt? --thanks, karl.
[libdirs.patch (text/x-patch, attachment)]
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.