GNU bug report logs - #59099
3-rd party aux files.

Previous Next

To reply to this bug, email your comments to 59099 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van de Bugger <van.de.bugger <at> yandex.ru>
To: <automake <at> gnu.org>
Subject: 3-rd party aux files.
Date: Sat, 29 Oct 2022 03:07:34 +0300

Hi,

I have several project using autoconf/automake. I also have several
helper scripts I use in all my makefiles. If I made any improvement in
one of these scripts, I have to copy that script to all my projects. It
is quite inconvenient and error-prone.

I think it would be nice if automake handles my helper scripts like
install-sh, missing, test-driver and other automake aux files. In such
a case all I need is just run

automake -af

to get helper scripts updated.

The only problem is that automake searches for missed aux files in the
*single* directory, /usr/share/automake-1.16 (*). If I use 

automake -af --libdir=$HOME/aux

it breaks automake (it can't find other files, e.g. am/header-vars.am).

So, my question: Is there any way to provide 3-rd party aux files?

---
(*) Putting my aux files to /usr/share/automake-1.16 is obviously a bad
idea. Even if I create package (rpm/deb/whatever else), it will depend
on automake version, so I will have to create almost identical packages
for automake 1.16, 1.15, ...

Message #10 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: van.de.bugger <at> yandex.ru
Cc: bug-automake <at> gnu.org
Subject: Re: bug#59099: 3-rd party aux files.
Date: Mon, 7 Nov 2022 16:37:42 -0700

Hi Van - first, I've copied your messages to the bug tracker, so please
use 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
(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
)

    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.

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van de Bugger <van.de.bugger <at> yandex.ru>
To: Karl Berry <karl <at> freefriends.org>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#59099: 3-rd party aux files.
Date: Mon, 07 Nov 2022 07:47:11 +0300

> If you, or anyone, can draft a patch, that would be great.

I think I could draft a patch, but I am not sure which interface to
choose for the new feature. I see few possible approaches:


1. Let automake look for aux files in *two* directories:
/usr/share/automake-1.16 and /usr/share/automake. In such case, the --
libdir option (and/or the AUTOMAKE_LIBDIR environment variable) will
replace the first dir (versioned one), the second dir (unversioned one)
is always searched for aux files.

This option looks good because automake uses similar approach when
searching for *.m4 files: it searches in /usr/share/aclocal-1.16 first,
then in /usr/share/aclocal. Disadvantage is that both directories are
not writable by non-privileged user.


2. Let automake maintain the *list* of directories to be searched for
aux files. 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.

Such approach looks good because non-privileged user can specify his
own aux directory. However, I worry about backward compatibility. Is
there any existing code relying on the fact that automake ignores
standard directory if the --libdir option is specified? It seems the --
libdir option is rarely used (manual states it is used primarily for
debugging), but I am not sure.


3. A combination of 1 and 2 is also possible. automake can maintain the
list of directories to be searched, which is initialized to
(/usr/share/automake-1.16, /usr/share/automake). The first directory
contains files provided by automake, the second — system-wide third-
party files, while non-privileged user is able to specify personal
directory in addition to system-wide directories either by the --libdir
option or by the AUTOMAKE_LIBDIRS environment variable.


Also, it is not clear to me, should it affect searching for *.am files
or not.

Any comments?


> ...my automake time is woefully scarce at the moment :(.

Not a problem, there is no hurry.

Thanks.

Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van de Bugger <van.de.bugger <at> yandex.ru>
To: Karl Berry <karl <at> freefriends.org>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#59099: 3-rd party aux files.
Date: Fri, 11 Nov 2022 00:47:40 +0300

> 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.

Not exactly. Truly per-project helper files is *not* a problem — they
can  be stored in the project, and so, do not require any support from
autotools. The problem if the same helper files are shared, i. e. used
in more than one project.

Also, I often pack my own scripts/programs/whatever-else (which can be
used, at least potentially, by others) to RPM packages, so I would like
to have system directory for them.

At the same time, user-writable directory is also wanted, if helper
files are not yet packed, or for test/debug purposes.

> In general, the closer the new behavior is to the existing, the 
> easier I think it will be to understand (and implement and document).

That's right. So I am not going to invent something new. Instead, I am
thinking about copying existing aclocal behavior: it already have all
the required pieces, documented, and in use for a long time:

1. Default directory for automake-provided files: /usr/share/aclocal-
VERSION.
2. It can be overridden by the ACLOCAL_AUTOMAKE_DIR env var.
3. It can be overridden by the --automake-acdir command line option.
4. Default directory for third-party system-wide files:
/usr/share/aclocal.
5. It can be overridden by the --system-acdir command line option.
6. Extra directories can be specified with "dirlist" file in the
directory for third-party system-wide files.
7. Extra directories can be specified by the -I command line option.
8. Extra directories can be specified by the ACLOCAL_PATH env var.
9. There is a mechanism to version aclocal files by using "#serial"
comment.

(The only thing I do not like is "dirlist" file. As described in the
Automake manual, this file is intended to be edited by system
administrator. In such a case, the proper location for the file would
be /etc directory, not /usr/share/aclocal.)

So, my draft proposal looks like:

1. A directory for automake-provided files: /usr/share/automake-VERSION
— already in place.
2. It can be overridden by the AUTOMAKE_LIBDIR env var — already in
place.
3. It can be overridden by the --libdir option — already in place.
4. A directory for third-party system-wide files — to do. Directory
will be, obviously, /usr/share/automake (non-versioned).
5. An option to override it — to do. --system-libdir?
6. Extra directories with "dirlist" — to do.
7. An option for extra directories -- to do. -I?
8. An env var for extra directories -- to to. AUTOMAKE_PATH?
9. "#serial" comment — to do.

Env var/option names could be more uniform, but backward compatibility
limits it.

> I think we should have Jim and/or other more experienced Automakers
> weigh in before you start coding. But here are my comments.

How to get it?

Message #19 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: van.de.bugger <at> yandex.ru
Cc: bug-automake <at> gnu.org
Subject: Re: bug#59099: 3-rd party aux files.
Date: Sat, 12 Nov 2022 14:26:47 -0700

    The problem if the same helper files are shared, i. e. used
    in more than one project.

Ack.

    thinking about copying existing aclocal behavior: 

Interesting and thorough, but I admit aclocal doesn't seem like a good
model to me. aclocal has to do complicated things because it is merging
individual macros into a single file, but what you need is simply a
system-wide directory to store new files, that don't exist
elsewhere. In general, simpler changes are better, for myriad reasons.

Automake already has --libdir/AUTOMAKE_LIBDIR to find library files. So
inventing a whole parallel mechanism seems like it would result in
confusion/clashes. Hence my idea of a new option+envvar
--libdirs/AUTOMAKE_LIBDIRS, essentially extending the automake libdir
into being a path. That still seems like a relatively straightforward
and sufficient solution, as I understand it. Wdyt?

I'm not sure about adding a default directory. /etc/automake comes to
mind, for the reasons you gave about the dirlist file, but I wonder if
distros already use /etc/automake for something or another. I don't know.

    4. A directory for third-party system-wide files — to
    do. Directory will be, obviously, /usr/share/automake (non-versioned).

/usr/share/automake was used by automake before the invention of
/usr/share/automake-VERSION. I don't know if anyone is still using those
(quite) old automake versions, but could be. Seems too confusing to
reuse it, in any case.

    6. Extra directories with "dirlist" — to do.

I wouldn't worry about anything like the dirlist file. There are enough
ways to set the directory.

    9. "#serial" comment — to do.

I also don't think there's a need to support a serial comment, because
automake doesn't do any such checking now for files in libdir. They are
just unconditionally used/copied. As far as I know. --best, karl.

Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van de Bugger <van.de.bugger <at> yandex.ru>
To: Karl Berry <karl <at> freefriends.org>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#59099: 3-rd party aux files.
Date: Mon, 14 Nov 2022 23:27:50 +0300

> Interesting and thorough, but I admit aclocal doesn't seem like
> a good model to me.

It could be not the best approach, but definitely good enough, since
(1) it is already exists, and (2) it is already exists in automake
(aclocal is a part of automake).

> aclocal has to do complicated things because it is merging
> individual macros into a single file…

In my eyes the difference is rather small. Both aclocal and automake
look for components in a number of sources and add them to the
projects. Whether it will be a single file aclocal.m4 or few files in
aux directory is a technical detail and does not really matter.

> Automake already has --libdir/AUTOMAKE_LIBDIR to find library
> files. So inventing a whole parallel mechanism seems like it
> would result in confusion/clashes.

W-w-w-wait a minute. I do **not** invent a new **parallel** mechanism,
a want to **extend** **existing** one by **reusing** **another**
**existing** mechanism. 

I did not study aclocal and automake source code, so I do not know how
easy to actually reuse aclocal code in automake; but it seems it is
possible since both tools are written in Perl. In any case, logically I
want reuse aclocal search algorithm in automake, I do not invent
anything new.

> Hence my idea of a new option+envvar --libdirs/AUTOMAKE_LIBDIRS…

Are --libdirs/AUTOMAKE_LIBDIRS exact names? I do not like them, because
you are going to keep --libdir/AUTOMAKE_LIBDIR for backward
compatibility. --libdir is too similar to --libdirs: one letter
difference in spelling, but the difference in behavior is striking. It
will be too easy to make a mistake.

> /usr/share/automake was used by automake before the invention
> of /usr/share/automake-VERSION. I don't know if anyone is still
> using those (quite) old automake versions, but could be.

Even so, I do not think it is an issue. Up to now, there is no 3-rd
party aux files. Automake documentation can list all existing aux files
(only 14 files) and indicate that these names are reserved. Future
automake aux files can be prefixed with am- or am_ to avoid clashes
with third-party aux files.

> I wouldn't worry about anything like the dirlist file. There
> are enough ways to set the directory.

dirlist file is documented, and documentations provide quite good
reasoning for it. In case of copying aclocal searching algorithm, I see
no reason to exclude dirlist.

> I also don't think there's a need to support a serial
> comment, because automake doesn't do any such checking now for
> files in libdir.

Up to now, all the aux files are coming from the same source — they are
provided by automake, so there is no need in versioning. But allowing
third-party aux files changes it.

Also, in case of copying aclocal searching algorithm, I see no reason
to exclude file versioning.

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)]

Message #30 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: van.de.bugger <at> ya.ru
Cc: bug-automake <at> gnu.org
Subject: Re: bug#59099: 3-rd party aux files.
Date: Thu, 10 Apr 2025 16:47:45 -0600

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

Message #33 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: Tue, 15 Apr 2025 11:37:11 +0300

[Message part 1 (text/markdown, inline)]

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

Message #36 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: van.de.bugger <at> ya.ru
Cc: bug-automake <at> gnu.org
Subject: Re: bug#59099: 3-rd party aux files.
Date: Wed, 16 Apr 2025 14:56:34 -0600

    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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.