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

Previous Next

Full log

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.

Previous Next

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