From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. Resent-From: Van de Bugger Original-Sender: "Debbugs-submit" Resent-CC: help-debbugs@gnu.org Resent-Date: Mon, 07 Nov 2022 08:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 59099 X-GNU-PR-Package: debbugs.gnu.org X-GNU-PR-Keywords: To: Received: via spool by submit@debbugs.gnu.org id=B.166780955425540 (code B ref -1); Mon, 07 Nov 2022 08:26:02 +0000 Received: (at submit) by debbugs.gnu.org; 7 Nov 2022 08:25:54 +0000 Received: from localhost ([127.0.0.1]:33181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orxS4-0006dr-TX for submit@debbugs.gnu.org; Mon, 07 Nov 2022 03:25:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:40596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orn0U-0001zN-Cw for submit@debbugs.gnu.org; Sun, 06 Nov 2022 16:16:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orn0U-00034m-82 for bug-automake@gnu.org; Sun, 06 Nov 2022 16:16:42 -0500 Received: from freefriends.org ([96.88.95.60]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orn0R-0002jA-An for bug-automake@gnu.org; Sun, 06 Nov 2022 16:16:41 -0500 Received: from freefriends.org (freefriends.org [96.88.95.60]) by freefriends.org (8.14.7/8.14.7) with ESMTP id 2A6LGYXw003579 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Nov 2022 14:16:35 -0700 Received: (from apache@localhost) by freefriends.org (8.14.7/8.14.7/Submit) id 2A6LGYNP003578; Sun, 6 Nov 2022 14:16:34 -0700 Resent-Date: Sun, 6 Nov 2022 14:16:34 -0700 Resent-From: Karl Berry Resent-Message-Id: <202211062116.2A6LGYNP003578@freefriends.org> Resent-To: bug-automake@gnu.org X-Envelope-From: automake-bounces+karl=freefriends.org@gnu.org X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1667002054; bh=bhphdbqPOrYVwQ3vxR0yHiyFGoJ+KH6/dgAVrkghmFs=; h=Date:To:From:Subject:Message-ID; b=d9f/iwtpQGfyH1Jc1jpORSfnGOLHp9EWyt7xQBucam/YSFmMnFTFFa2HAtpBtdRUj kjhk6Pqg98hU0Au2Zo72OaMQ175xjt1M5MynLVjWnZlSU8o8In8225GVVfP7Lb0i59 iCbyAb1/EHwd8HCemWsm1QRyIcx9+yrAflEXM8lg= Authentication-Results: myt5-2f5ba0466eb8.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <9ec7c3e2dd374b115685fbd88107b16d98afc039.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 Received-SPF: pass client-ip=77.88.28.109; envelope-from=van.de.bugger@yandex.ru; helo=forward106p.mail.yandex.net X-Spam_action: no action X-Mailman-Approved-At: Sat, 29 Oct 2022 00:27:08 -0400 X-BeenThere: automake@gnu.org X-Mailman-Version: 2.1.29 Precedence: list X-MIME-Autoconverted: from quoted-printable to 8bit by freefriends.org id 29T5Yb1d018171 Content-Transfer-Encoding: 7bit Date: Sat, 29 Oct 2022 03:07:34 +0300 From: Van de Bugger Received-SPF: pass client-ip=96.88.95.60; envelope-from=karl@freefriends.org; helo=freefriends.org X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_40=-0.001, CTE_8BIT_MISMATCH=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.1 (--) X-Mailman-Approved-At: Mon, 07 Nov 2022 03:25:51 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) 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, ... From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 07 16:05:52 2022 Received: (at control) by debbugs.gnu.org; 7 Nov 2022 21:05:52 +0000 Received: from localhost ([127.0.0.1]:35554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1os9JY-00087p-9s for submit@debbugs.gnu.org; Mon, 07 Nov 2022 16:05:52 -0500 Received: from freefriends.org ([96.88.95.60]:45878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1os9JW-00087g-UP for control@debbugs.gnu.org; Mon, 07 Nov 2022 16:05:51 -0500 X-Envelope-From: karl@freefriends.org X-Envelope-To: Received: from freefriends.org (freefriends.org [96.88.95.60]) by freefriends.org (8.14.7/8.14.7) with ESMTP id 2A7L5n2O026236 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 7 Nov 2022 14:05:50 -0700 Received: (from apache@localhost) by freefriends.org (8.14.7/8.14.7/Submit) id 2A7L5n4Q026235; Mon, 7 Nov 2022 14:05:49 -0700 Date: Mon, 7 Nov 2022 14:05:49 -0700 Message-Id: <202211072105.2A7L5n4Q026235@freefriends.org> From: Karl Berry To: control@debbugs.gnu.org Subject: X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) reassign 59099 automake From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. References: <9ec7c3e2dd374b115685fbd88107b16d98afc039.camel@yandex.ru> Resent-From: Karl Berry Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 07 Nov 2022 23:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59099 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: van.de.bugger@yandex.ru Cc: 59099@debbugs.gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.166786427230788 (code B ref -1); Mon, 07 Nov 2022 23:38:02 +0000 Received: (at submit) by debbugs.gnu.org; 7 Nov 2022 23:37:52 +0000 Received: from localhost ([127.0.0.1]:35739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osBge-00080V-3L for submit@debbugs.gnu.org; Mon, 07 Nov 2022 18:37:52 -0500 Received: from lists.gnu.org ([209.51.188.17]:56178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osBgb-00080N-FW for submit@debbugs.gnu.org; Mon, 07 Nov 2022 18:37:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osBgb-00031m-9I for bug-automake@gnu.org; Mon, 07 Nov 2022 18:37:49 -0500 Received: from freefriends.org ([96.88.95.60]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osBgY-0005dH-8t for bug-automake@gnu.org; Mon, 07 Nov 2022 18:37:49 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (freefriends.org [96.88.95.60]) by freefriends.org (8.14.7/8.14.7) with ESMTP id 2A7NbhNX013193 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Nov 2022 16:37:44 -0700 Received: (from apache@localhost) by freefriends.org (8.14.7/8.14.7/Submit) id 2A7NbgaM013192; Mon, 7 Nov 2022 16:37:42 -0700 Date: Mon, 7 Nov 2022 16:37:42 -0700 Message-Id: <202211072337.2A7NbgaM013192@freefriends.org> From: Karl Berry In-Reply-To: <9ec7c3e2dd374b115685fbd88107b16d98afc039.camel@yandex.ru> Received-SPF: pass client-ip=96.88.95.60; envelope-from=karl@freefriends.org; helo=freefriends.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi Van - first, I've copied your messages to the bug tracker, so please use bug-automake@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. From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. Resent-From: Van de Bugger Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 08 Nov 2022 08:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59099 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry Cc: 59099@debbugs.gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16678957181903 (code B ref -1); Tue, 08 Nov 2022 08:22:02 +0000 Received: (at submit) by debbugs.gnu.org; 8 Nov 2022 08:21:58 +0000 Received: from localhost ([127.0.0.1]:36201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osJro-0000Uc-GY for submit@debbugs.gnu.org; Tue, 08 Nov 2022 03:21:57 -0500 Received: from lists.gnu.org ([209.51.188.17]:55078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osAR9-0005u5-Mf for submit@debbugs.gnu.org; Mon, 07 Nov 2022 17:17:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osAR2-00080z-9m for bug-automake@gnu.org; Mon, 07 Nov 2022 17:17:47 -0500 Received: from freefriends.org ([96.88.95.60]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osAQz-00059N-JQ for bug-automake@gnu.org; Mon, 07 Nov 2022 17:17:39 -0500 Received: from freefriends.org (freefriends.org [96.88.95.60]) by freefriends.org (8.14.7/8.14.7) with ESMTP id 2A7MHXX3003089 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Nov 2022 15:17:34 -0700 Received: (from apache@localhost) by freefriends.org (8.14.7/8.14.7/Submit) id 2A7MHXHT003087; Mon, 7 Nov 2022 15:17:33 -0700 X-Envelope-From: van.de.bugger@yandex.ru X-Envelope-To: X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1667796432; bh=A1hvEG+ZnqkQiYY9UtQJT9yBdcPy1TwQwb3aIq87Eiw=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=FmkPoy+s9bUEELO5Y/ZioTsajUACtLmtzfgJlSg6xvT1GzXUfACH3S1t7jYdsa3Df 3d8/sDSHil2pifXRdi48Bkfk92HK2eiSoOU3QOqCrGFca0MlSQ9ueX/xL+1MACmakM s2N+nqZPoHtxtJTiVa2W+G3e2ThlvsSm1sP3FwFc= Authentication-Results: vla5-1ef2161cc1d7.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: In-Reply-To: <202211062116.2A6LGiN7003663@freefriends.org> References: <202211062116.2A6LGiN7003663@freefriends.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by freefriends.org id 2A74lEnl025806 Content-Transfer-Encoding: 7bit Date: Mon, 07 Nov 2022 07:47:11 +0300 From: Van de Bugger Received-SPF: pass client-ip=96.88.95.60; envelope-from=karl@freefriends.org; helo=freefriends.org X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, DATE_IN_PAST_12_24=1.049, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.0 (/) X-Mailman-Approved-At: Tue, 08 Nov 2022 03:21:55 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 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. From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. Resent-From: Van de Bugger Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Fri, 11 Nov 2022 04:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59099 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry Cc: 59099@debbugs.gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.166814078732359 (code B ref -1); Fri, 11 Nov 2022 04:27:01 +0000 Received: (at submit) by debbugs.gnu.org; 11 Nov 2022 04:26:27 +0000 Received: from localhost ([127.0.0.1]:44809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1otLcX-0008Pq-Il for submit@debbugs.gnu.org; Thu, 10 Nov 2022 23:26:27 -0500 Received: from lists.gnu.org ([209.51.188.17]:52230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1otFOo-0004ny-8w for submit@debbugs.gnu.org; Thu, 10 Nov 2022 16:47:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1otFOo-0000j8-3f for bug-automake@gnu.org; Thu, 10 Nov 2022 16:47:50 -0500 Received: from forward501j.mail.yandex.net ([5.45.198.251]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1otFOl-0004LX-7D for bug-automake@gnu.org; Thu, 10 Nov 2022 16:47:49 -0500 Received: from iva4-143b1447cf50.qloud-c.yandex.net (iva4-143b1447cf50.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:7511:0:640:143b:1447]) by forward501j.mail.yandex.net (Yandex) with ESMTP id DA8A962321C; Fri, 11 Nov 2022 00:47:41 +0300 (MSK) Received: by iva4-143b1447cf50.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id IANymEDn9e-lfWSWDcY; Fri, 11 Nov 2022 00:47:41 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1668116861; bh=xd6S3PbfsoWAT7Iff/UbhpcpDBxjy84VjtUR8JWqHe0=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=QvC6fNW/eQ/sShNe+s8yBhaIa8tYD0GKUSMnUpBmmQwTDXe2bx9ufPyqOyYK7oPLC k7oXpqeoqgf1acK5U2PJOZdRRDxALqlJseO3Je9EnTnCOwnYHXicHEETt5urxsAntU SSzVaoHwyAUYsvQMpB+5keN7qrviy5xfv2X9Y8Sk= Authentication-Results: iva4-143b1447cf50.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <2be4f6f4fb8b507651ec9c789491c072a86b6c14.camel@yandex.ru> From: Van de Bugger Date: Fri, 11 Nov 2022 00:47:40 +0300 In-Reply-To: <202211072337.2A7NbgaM013192@freefriends.org> References: <202211072337.2A7NbgaM013192@freefriends.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 Received-SPF: pass client-ip=5.45.198.251; envelope-from=van.de.bugger@yandex.ru; helo=forward501j.mail.yandex.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Mailman-Approved-At: Thu, 10 Nov 2022 23:26:25 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > 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 =E2=80=94 th= ey 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=C2=A0 > 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 =E2=80=94 already in place. 2. It can be overridden by the AUTOMAKE_LIBDIR env var =E2=80=94 already in place. 3. It can be overridden by the --libdir option =E2=80=94 already in place. 4. A directory for third-party system-wide files =E2=80=94 to do. Directory will be, obviously, /usr/share/automake (non-versioned). 5. An option to override it =E2=80=94 to do. --system-libdir? 6. Extra directories with "dirlist" =E2=80=94 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 =E2=80=94 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? From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. References: <9ec7c3e2dd374b115685fbd88107b16d98afc039.camel@yandex.ru> Resent-From: Karl Berry Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Sat, 12 Nov 2022 21:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59099 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: van.de.bugger@yandex.ru Cc: 59099@debbugs.gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.166828841617907 (code B ref -1); Sat, 12 Nov 2022 21:27:01 +0000 Received: (at submit) by debbugs.gnu.org; 12 Nov 2022 21:26:56 +0000 Received: from localhost ([127.0.0.1]:49464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oty1f-0004ek-Mv for submit@debbugs.gnu.org; Sat, 12 Nov 2022 16:26:55 -0500 Received: from lists.gnu.org ([209.51.188.17]:57220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oty1d-0004eb-BD for submit@debbugs.gnu.org; Sat, 12 Nov 2022 16:26:54 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oty1d-0007YC-5f for bug-automake@gnu.org; Sat, 12 Nov 2022 16:26:53 -0500 Received: from freefriends.org ([96.88.95.60]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oty1b-000143-6T for bug-automake@gnu.org; Sat, 12 Nov 2022 16:26:52 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (freefriends.org [96.88.95.60]) by freefriends.org (8.14.7/8.14.7) with ESMTP id 2ACLQmKG016506 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Nov 2022 14:26:49 -0700 Received: (from apache@localhost) by freefriends.org (8.14.7/8.14.7/Submit) id 2ACLQls5016497; Sat, 12 Nov 2022 14:26:47 -0700 Date: Sat, 12 Nov 2022 14:26:47 -0700 Message-Id: <202211122126.2ACLQls5016497@freefriends.org> From: Karl Berry In-Reply-To: <2be4f6f4fb8b507651ec9c789491c072a86b6c14.camel@yandex.ru> Received-SPF: pass client-ip=96.88.95.60; envelope-from=karl@freefriends.org; helo=freefriends.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) 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. From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. Resent-From: Van de Bugger Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 14 Nov 2022 23:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59099 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry Cc: 59099@debbugs.gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.166846765832325 (code B ref -1); Mon, 14 Nov 2022 23:15:03 +0000 Received: (at submit) by debbugs.gnu.org; 14 Nov 2022 23:14:18 +0000 Received: from localhost ([127.0.0.1]:51211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouief-0008P3-Im for submit@debbugs.gnu.org; Mon, 14 Nov 2022 18:14:18 -0500 Received: from lists.gnu.org ([209.51.188.17]:58398) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouieL-0008JF-8F for submit@debbugs.gnu.org; Mon, 14 Nov 2022 18:13:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouieK-0002SL-Hw for bug-automake@gnu.org; Mon, 14 Nov 2022 18:13:56 -0500 Received: from forward503o.mail.yandex.net ([2a02:6b8:0:1a2d::613]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oug3i-0007Ie-Ut for bug-automake@gnu.org; Mon, 14 Nov 2022 15:28:00 -0500 Received: from iva2-0a73a57cc944.qloud-c.yandex.net (iva2-0a73a57cc944.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:6985:0:640:a73:a57c]) by forward503o.mail.yandex.net (Yandex) with ESMTP id 38AC25C42AD; Mon, 14 Nov 2022 23:27:52 +0300 (MSK) Received: by iva2-0a73a57cc944.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id cAzW9sVpOm-RpWeMLh3; Mon, 14 Nov 2022 23:27:51 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1668457671; bh=P8kVgZwhcwCKPMugrjqXM+KiGERR2tuv0lK9qQPrQJ4=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=MgsedJHNIRU3RCvxWdyaaq1DyqIpezvRICkpLLwcbc4P4erqvgBQay6LP47Ftwlvy LOQ7z6qfigEy8mtR6H0aijmrBaM3jKdld0Jm5/IjOoJmcr0LlktUEFfA3ZrgModw4C zMNVS1TEMoSyy6QgTWipc/gjqKL6ZTMG1pbQCbho= Authentication-Results: iva2-0a73a57cc944.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: From: Van de Bugger Date: Mon, 14 Nov 2022 23:27:50 +0300 In-Reply-To: <202211122126.2ACLQls5016497@freefriends.org> References: <202211122126.2ACLQls5016497@freefriends.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 Received-SPF: pass client-ip=2a02:6b8:0:1a2d::613; envelope-from=van.de.bugger@yandex.ru; helo=forward503o.mail.yandex.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > 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=E2=80=A6 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.=C2=A0 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=E2=80=A6 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 =E2=80=94 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 13 00:41:28 2023 Received: (at control) by debbugs.gnu.org; 13 Jan 2023 05:41:28 +0000 Received: from localhost ([127.0.0.1]:49155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pGCoi-0006Hb-1A for submit@debbugs.gnu.org; Fri, 13 Jan 2023 00:41:28 -0500 Received: from woodpecker.gentoo.org ([140.211.166.183]:38864 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pGCog-0006HN-Go for control@debbugs.gnu.org; Fri, 13 Jan 2023 00:41:26 -0500 Received: by smtp.gentoo.org (Postfix, from userid 559) id ED693340B53; Fri, 13 Jan 2023 05:41:20 +0000 (UTC) From: Mike Frysinger To: control@debbugs.gnu.org Subject: Control message Message-Id: <20230113054120.ED693340B53@smtp.gentoo.org> Date: Fri, 13 Jan 2023 05:41:20 +0000 (UTC) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) severity 59099 wishlist thankyou From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. Resent-From: Van de Bugger Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Sat, 01 Mar 2025 19:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59099 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry Cc: 59099@debbugs.gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.174085604415819 (code B ref -1); Sat, 01 Mar 2025 19:08:02 +0000 Received: (at submit) by debbugs.gnu.org; 1 Mar 2025 19:07:24 +0000 Received: from localhost ([127.0.0.1]:43874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toSBF-00046k-Aw for submit@debbugs.gnu.org; Sat, 01 Mar 2025 14:07:24 -0500 Received: from lists.gnu.org ([2001:470:142::17]:52834) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1toQIT-0007rb-Ro for submit@debbugs.gnu.org; Sat, 01 Mar 2025 12:06:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1toQIN-0006je-HN for bug-automake@gnu.org; Sat, 01 Mar 2025 12:06:35 -0500 Received: from forward502d.mail.yandex.net ([2a02:6b8:c41:1300:1:45:d181:d502]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1toQIJ-0006Ts-Bp for bug-automake@gnu.org; Sat, 01 Mar 2025 12:06:35 -0500 Received: from mail-nwsmtp-smtp-production-main-80.klg.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-80.klg.yp-c.yandex.net [IPv6:2a02:6b8:c43:4587:0:640:bf04:0]) by forward502d.mail.yandex.net (Yandex) with ESMTPS id 0C4DB6099F; Sat, 1 Mar 2025 20:06:23 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-80.klg.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id L6k4e6BLmmI0-HtxP3rmY; Sat, 01 Mar 2025 20:06:22 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1740848782; bh=Q/RC7gbDEkQk4mYj7i4ghYIvcBSmWGfPZnBWVRRgJks=; h=Date:In-Reply-To:Cc:References:To:From:Subject:Message-ID; b=d6XtSjOlc/JbaXKZqeQ+nj4b9TwV1G1ypXzZk+tUnpbB9GIjLTm2KuDMJ1fYkRqzB lkHTLX3nFytF9BSq/A+gxcPx4yHr7oyFWd8bCoyuDm7m80A6It0CFLG7jdByQR1nwq g2seLCYoWWpNVV28syCXEflbj9Su9mHZXF5VE95A= Authentication-Results: mail-nwsmtp-smtp-production-main-80.klg.yp-c.yandex.net; dkim=pass header.i=@ya.ru Message-ID: <09e4c245ac95be8b64bfb74540f9ece96ec724a6.camel@ya.ru> From: Van de Bugger Date: Sat, 01 Mar 2025 20:06:21 +0300 In-Reply-To: <202211072337.2A7NbgaM013192@freefriends.org> References: <202211072337.2A7NbgaM013192@freefriends.org> Content-Type: multipart/mixed; boundary="=-MYh/6pbnU7pq4lV8YVns" User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 Received-SPF: pass client-ip=2a02:6b8:c41:1300:1:45:d181:d502; envelope-from=van.de.bugger@ya.ru; helo=forward502d.mail.yandex.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Mailman-Approved-At: Sat, 01 Mar 2025 14:07:20 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-MYh/6pbnU7pq4lV8YVns Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, > Since the purpose of the new feature is to support per-project helper > files (right?)=E2=80=A6 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=20 $ autoreconf -i > What comes to mind follows your typo above :) That wasn't a typo. I was going to introduce AUTOMAKE_LIBDIRS environment variable. =E2=81=82 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. =E2=81=82 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.=C2=A0 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. =E2=81=82 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/fedo= ra-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.=20 =E2=81=82 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. =E2=81=82 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 =20 > use [bug-automake@gnu.org](mailto:bug-automake@gnu.org)=C2=A0and the give= n subject line so things stay in =20 > the bug going forward. =20 > [https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D59099](https://debbugs.gnu= .org/cgi/bugreport.cgi?bug=3D59099) =20 > (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: =20 > [https://lists.gnu.org/archive/html/automake/2022-11/msg00001.html](https:/= /lists.gnu.org/archive/html/automake/2022-11/msg00001.html) =20 > ) >=20 > =C2=A0=C2=A0=C2=A0 I am not sure which interface to choose for the new fe= ature. I see =20 > =C2=A0=C2=A0=C2=A0 few possible approaches: >=20 > Your summary is admirable :).=C2=A0 I think we should have Jim and/or other =20 > more experienced Automakers weigh in before you start coding. But here =20 > are my comments. >=20 > =C2=A0=C2=A0=C2=A0 Disadvantage is that both directories are =20 > =C2=A0=C2=A0=C2=A0 not writable by non-privileged user. >=20 > 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 =20 > mess around with system directories if we can help it. >=20 > =C2=A0=C2=A0=C2=A0 2. Let automake maintain the *list* of directories to = be searched for =20 > =C2=A0=C2=A0=C2=A0 aux files. >=20 > Sounds right. >=20 > =C2=A0=C2=A0=C2=A0 In such case, the --libdir=C2=A0 option (and the AUTOM= AKE_LIBDIRS =20 > =C2=A0=C2=A0=C2=A0 environment variable) will insert the given directory = to the beginning =20 > =C2=A0=C2=A0=C2=A0 (or to the end?) of the list. Multiple --libdir option= s are allowed. >=20 > I like the idea in general. >=20 > =C2=A0=C2=A0=C2=A0 Is there any existing code relying on the fact that au= tomake ignores =20 > =C2=A0=C2=A0=C2=A0 standard directory if the --libdir option is specified= ? >=20 > The answer to the question "does anything depend on X", for any Automake =20 > (or Autoconf) behavior X, is yes.=C2=A0 So I think we must not change = =20 > existing behavior of --libdir or AUTOMAKE_LIBDIR. Instead, we can add to it. >=20 > What comes to mind follows your typo above :) ... have a new =20 > option/envvar --libdirs/AUTOMAKE_LIBDIRS which maintains an independent =20 > list of directories to search. I think the new dirs should be searched =20 > after the libdir/AUTOMAKE_LIBDIR directory. >=20 > I think the list of dirs should be searched in the order specified: =20 > --libdirs foo --libdirs bar would search foo then bar. >=20 > As with --libdir/AUTOMAKE_LIBDIR, if --libdirs is specified, it would > override (completely) AUTOMAKE_LIBDIRS. No such "extra" directories =20 > would be searched by default. >=20 > Does that reasonably solve your original request? >=20 > =C2=A0=C2=A0=C2=A0 Also, it is not clear to me, should it affect searchin= g for *.am > =C2=A0=C2=A0=C2=A0 files or not. >=20 > For consistency, I think the new searching should look for the same =20 > files as the existing searching. Presumably that will be =20 > easiest/cleanest to implement, too. >=20 > In general, the closer the new behavior is to the existing, the easier I =20 > think it will be to understand (and implement and document). >=20 > Wdyt? --thanks, karl. --=-MYh/6pbnU7pq4lV8YVns Content-Disposition: attachment; filename="libdirs.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="libdirs.patch"; charset="UTF-8" ZGlmZiAtdXIgYS9iaW4vYXV0b21ha2UuaW4gYi9iaW4vYXV0b21ha2UuaW4KLS0tIGEvYmluL2F1 dG9tYWtlLmluCTIwMjEtMDktMjAgMDM6NTM6MTQuMDAwMDAwMDAwICswMzAwCisrKyBiL2Jpbi9h dXRvbWFrZS5pbgkyMDI1LTAzLTAxIDE3OjI4OjUwLjY1NjEwNjU0MCArMDMwMApAQCAtODcsNiAr ODcsNyBAQAogc3ViIGRlZmluZV92ZXJib3NlX2xpYnRvb2wgKCk7CiBzdWIgZGVmaW5lX3ZlcmJv c2VfdGV4aW5mbyAoKTsKIHN1YiBkb19jaGVja19tZXJnZV90YXJnZXQgKCk7CitzdWIgZmluYWxp emVfbGliZGlycyAoKTsKIHN1YiBnZXRfbnVtYmVyX29mX3RocmVhZHMgKCk7CiBzdWIgaGFuZGxl X2NvbXBpbGUgKCk7CiBzdWIgaGFuZGxlX2RhdGEgKCk7CkBAIC0yODMsNiArMjg0LDggQEAKICMg VFJVRSBpZiB3ZSBzaG91bGQgYWx3YXlzIHVwZGF0ZSBmaWxlcyB0aGF0IHdlIGtub3cgYWJvdXQu CiBteSAkZm9yY2VfbWlzc2luZyA9IDA7CiAKKyMgTGlzdCBvZiBkaXJlY3RvcmllcyB0byBsb29r IGZvciBmaWxlcy4KK215IEBsaWJkaXJzOwogCiAjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tICMjCiAjIyBWYXJpYWJsZXMgZmlsbGVkIGR1cmluZyBmaWxlcyBzY2Fu bmluZy4gICMjCkBAIC0yNTEyLDcgKzI1MTUsNyBAQAogICAgIH0KIAogICAgIG15ICgkY29tcywg JHZhcnMsICRydWxlcykgPQotICAgICAgZmlsZV9jb250ZW50c19pbnRlcm5hbCAoMSwgIiRsaWJk aXIvYW0vY29tcGlsZS5hbSIsCisgICAgICBmaWxlX2NvbnRlbnRzX2ludGVybmFsICgxLCBmaW5k X2ZpbGUgKCJhbS9jb21waWxlLmFtIiwgQGxpYmRpcnMpLAogCQkJICAgICAgbmV3IEF1dG9tYWtl OjpMb2NhdGlvbiwKIAkJCSAgICAgICdERUZBVUxUX0lOQ0xVREVTJyA9PiAkZGVmYXVsdF9pbmNs dWRlcywKIAkJCSAgICAgICdNT1NUTFlSTVMnID0+IGpvaW4gKCJcbiIsIEBtb3N0bHlfcm1zKSwK QEAgLTY3MzksNyArNjc0Miw3IEBACiB7CiAgIG15ICRzYXZlZF9vdXRwdXRfdmFycyA9ICRvdXRw dXRfdmFyczsKICAgbXkgKCRjb21tZW50cywgdW5kZWYsICRydWxlcykgPQotICAgIGZpbGVfY29u dGVudHNfaW50ZXJuYWwgKDEsICIkbGliZGlyL2FtL2hlYWRlci12YXJzLmFtIiwKKyAgICBmaWxl X2NvbnRlbnRzX2ludGVybmFsICgxLCBmaW5kX2ZpbGUgKCJhbS9oZWFkZXItdmFycy5hbSIsIEBs aWJkaXJzKSwKIAkJCSAgICBuZXcgQXV0b21ha2U6OkxvY2F0aW9uKTsKIAogICBmb3JlYWNoIG15 ICR2YXIgKHNvcnQga2V5cyAlY29uZmlndXJlX3ZhcnMpCkBAIC02OTYzLDcgKzY5NjYsNyBAQAog IyAoJENPTU1FTlQsICRWQVJJQUJMRVMsICRSVUxFUykKICMgZmlsZV9jb250ZW50c19pbnRlcm5h bCAoJElTX0FNLCAkRklMRSwgJFdIRVJFLCBbJVRSQU5TRk9STV0pCiAjIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotIyBSZXR1cm4g Y29udGVudHMgb2YgYSBmaWxlIGZyb20gJGxpYmRpci9hbSwgYXV0b21hdGljYWxseSBza2lwcGlu ZworIyBSZXR1cm4gY29udGVudHMgb2YgYSBmaWxlIGZyb20gbGliZGlyL2FtLCBhdXRvbWF0aWNh bGx5IHNraXBwaW5nCiAjIG1hY3JvcyBvciBydWxlcyB3aGljaCBhcmUgYWxyZWFkeSBrbm93bi4g JElTX0FNIGlmZiB0aGUgY2FsbGVyIGlzCiAjIHJlYWRpbmcgYW4gQXV0b21ha2UgZmlsZSAoYXMg b3Bwb3NlZCB0byB0aGUgdXNlcidzIE1ha2VmaWxlLmFtKS4KIHN1YiBmaWxlX2NvbnRlbnRzX2lu dGVybmFsCkBAIC03MDE3LDcgKzcwMjAsNyBAQAogCXsKIAkgICAgaWYgKCRjb25kICE9IEZBTFNF KQogCSAgICAgIHsKLQkJbXkgJGZpbGUgPSAoJGlzX2FtID8gIiRsaWJkaXIvYW0vIiA6ICcnKSAu ICQxOworCQlteSAkZmlsZSA9ICRpc19hbSA/IGZpbmRfZmlsZSAoImFtLyQxIiwgQGxpYmRpcnMp IDogJDE7CiAJCSR3aGVyZS0+cHVzaF9jb250ZXh0ICgiJyRmaWxlJyBpbmNsdWRlZCBmcm9tIGhl cmUiKTsKIAkJIyBOLWFyeSAnLj0nIGZhaWxzLgogCQlteSAoJGNvbSwgJHZhcnMsICRydWxlcykK QEAgLTcxNTYsMTMgKzcxNTksMTMgQEAKICMgJENPTlRFTlRTCiAjIGZpbGVfY29udGVudHMgKCRC QVNFTkFNRSwgJFdIRVJFLCBbJVRSQU5TRk9STV0pCiAjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIFJldHVybiBjb250ZW50cyBvZiBhIGZpbGUgZnJv bSAkbGliZGlyL2FtLCBhdXRvbWF0aWNhbGx5IHNraXBwaW5nCisjIFJldHVybiBjb250ZW50cyBv ZiBhIGZpbGUgZnJvbSBsaWJkaXIvYW0sIGF1dG9tYXRpY2FsbHkgc2tpcHBpbmcKICMgbWFjcm9z IG9yIHJ1bGVzIHdoaWNoIGFyZSBhbHJlYWR5IGtub3duLgogc3ViIGZpbGVfY29udGVudHMKIHsK ICAgICBteSAoJGJhc2VuYW1lLCAkd2hlcmUsICV0cmFuc2Zvcm0pID0gQF87CiAgICAgbXkgKCRj b21tZW50cywgJHZhcmlhYmxlcywgJHJ1bGVzKSA9Ci0gICAgICBmaWxlX2NvbnRlbnRzX2ludGVy bmFsICgxLCAiJGxpYmRpci9hbS8kYmFzZW5hbWUuYW0iLCAkd2hlcmUsCisgICAgICBmaWxlX2Nv bnRlbnRzX2ludGVybmFsICgxLCBmaW5kX2ZpbGUgKCJhbS8kYmFzZW5hbWUuYW0iLCBAbGliZGly cyksICR3aGVyZSwKIAkJCSAgICAgICV0cmFuc2Zvcm0pOwogICAgIHJldHVybiAiJGNvbW1lbnRz JHZhcmlhYmxlcyRydWxlcyI7CiB9CkBAIC03NjU1LDcgKzc2NTgsNyBAQAogICBteSAkbWVzc2Fn ZSA9ICJyZXF1aXJlZCBmaWxlICckZnVsbGZpbGUnIG5vdCBmb3VuZCI7CiAgIGlmICgkYWRkX21p c3NpbmcpCiAgICAgewotICAgICAgaWYgKC1mICIkbGliZGlyLyRmaWxlIikKKyAgICAgIGlmICht eSAkbGliZmlsZSA9IGZpbmRfZmlsZSAoJGZpbGUsIEBsaWJkaXJzLCB7b3B0aW9uYWw9PjF9KSkK ICAgICAgICAgewogICAgICAgICAgICRzdXBwcmVzcyA9IDE7CiAKQEAgLTc2NzksMTQgKzc2ODIs MTQgQEAKICAgICAgICAgICB1bmxpbmsgKCRmdWxsZmlsZSkgaWYgLWYgJGZ1bGxmaWxlOwogICAg ICAgICAgIGlmICgkc3ltbGlua19leGlzdHMgJiYgISAkY29weV9taXNzaW5nKQogICAgICAgICAg ICAgewotICAgICAgICAgICAgICBpZiAoISBzeW1saW5rICgiJGxpYmRpci8kZmlsZSIsICRmdWxs ZmlsZSkKKyAgICAgICAgICAgICAgaWYgKCEgc3ltbGluayAoJGxpYmZpbGUsICRmdWxsZmlsZSkK ICAgICAgICAgICAgICAgICAgIHx8ICEgLWUgJGZ1bGxmaWxlKQogICAgICAgICAgICAgICAgIHsK ICAgICAgICAgICAgICAgICAgICRzdXBwcmVzcyA9IDA7CiAgICAgICAgICAgICAgICAgICAkdHJh aWxlciA9ICI7IGVycm9yIHdoaWxlIG1ha2luZyBsaW5rOiAkISI7CiAgICAgICAgICAgICAgICAg fQogICAgICAgICAgICAgfQotICAgICAgICAgIGVsc2lmIChzeXN0ZW0gKCdjcCcsICIkbGliZGly LyRmaWxlIiwgJGZ1bGxmaWxlKSkKKyAgICAgICAgICBlbHNpZiAoc3lzdGVtICgnY3AnLCAkbGli ZmlsZSwgJGZ1bGxmaWxlKSkKICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgJHN1cHByZXNz ID0gMDsKICAgICAgICAgICAgICAgJHRyYWlsZXIgPSAiXG4gICAgZXJyb3Igd2hpbGUgY29weWlu ZyI7CkBAIC03Njk3LDcgKzc3MDAsNyBAQAogICBlbHNlCiAgICAgewogICAgICAgJHRyYWlsZXIg PSAiXG4gICdhdXRvbWFrZSAtLWFkZC1taXNzaW5nJyBjYW4gaW5zdGFsbCAnJGZpbGUnIgotICAg ICAgICBpZiAtZiAiJGxpYmRpci8kZmlsZSI7CisgICAgICAgIGlmIGZpbmRfZmlsZSAoJGZpbGUs IEBsaWJkaXJzLCB7b3B0aW9uYWw9PjF9KTsKICAgICB9CiAKICAgIyBJZiAtLWZvcmNlLW1pc3Np bmcgd2FzIHNwZWNpZmllZCwgYW5kIHdlIGhhdmUKQEAgLTgyNTIsOCArODI1NSw5IEBACiAgICAg KAogICAgICAndmVyc2lvbicgPT4gXCZ2ZXJzaW9uLAogICAgICAnaGVscCcgICAgPT4gXCZ1c2Fn ZSwKLSAgICAgJ2xpYmRpcj1zJwk9PiBcJGxpYmRpciwKLSAgICAgJ3ByaW50LWxpYmRpcicgICAg ID0+IHN1YiB7IHByaW50ICIkbGliZGlyXG4iOyBleGl0IDA7IH0sCisgICAgICdsaWJkaXI9cycJ PT4gXEBsaWJkaXJzLAorICAgICAncHJpbnQtbGliZGlycycgICAgPT4gc3ViIHsgZmluYWxpemVf bGliZGlycyAoKTsgbG9jYWwgJCIgPSAkcGF0aF9zZXA7CisgICAgICAgcHJpbnQgIkBsaWJkaXJz XG4iOyBleGl0IDA7IH0sCiAgICAgICdnbnUnCQk9PiBzdWIgeyAkc3RyaWN0ID0gJ2dudSc7IH0s CiAgICAgICdnbml0cycJCT0+IHN1YiB7ICRzdHJpY3QgPSAnZ25pdHMnOyB9LAogICAgICAnZm9y ZWlnbicJCT0+IHN1YiB7ICRzdHJpY3QgPSAnZm9yZWlnbic7IH0sCkBAIC04MjcwLDYgKzgyNzQs OCBAQAogICB1c2UgQXV0b21ha2U6OkdldG9wdCAoKTsKICAgQXV0b21ha2U6OkdldG9wdDo6cGFy c2Vfb3B0aW9ucyAlY2xpX29wdGlvbnM7CiAKKyAgZmluYWxpemVfbGliZGlycyAoKTsKKwogICBz ZXRfc3RyaWN0bmVzcyAoJHN0cmljdCk7CiAgIG15ICRjbGlfd2hlcmUgPSBuZXcgQXV0b21ha2U6 OkxvY2F0aW9uOwogICBzZXRfZ2xvYmFsX29wdGlvbiAoJ25vLWRlcGVuZGVuY2llcycsICRjbGlf d2hlcmUpIGlmICRpZ25vcmVfZGVwczsKQEAgLTgzMDIsNiArODMwOCwxNCBAQAogICAgIGlmICRl cnJzcGVjICYmICEgQGlucHV0X2ZpbGVzOwogfQogCitzdWIgZmluYWxpemVfbGliZGlycyAoKQor eworICBwdXNoKEBsaWJkaXJzLCAkRU5We0FVVE9NQUtFX0xJQkRJUn0gLy8gJycpOworICBwdXNo KEBsaWJkaXJzLCBzcGxpdCgvXFEkcGF0aF9zZXBcRS8sICRFTlZ7QVVUT01BS0VfTElCRElSU30g Ly8gJycpKTsKKyAgcHVzaChAbGliZGlycywgIiRkYXRhZGlyLyRQQUNLQUdFIiwgIiRkYXRhZGly LyRQQUNLQUdFLSRBUElWRVJTSU9OIikKKyAgICB1bmxlc3MgJEVOVntBVVRPTUFLRV9VTklOU1RB TExFRH07CisgIEBsaWJkaXJzID0gZ3JlcCh7JF8gbmUgJyd9IEBsaWJkaXJzKTsKK30KIAogIyBo YW5kbGVfbWFrZWZpbGUgKCRNQUtFRklMRSkKICMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t CmRpZmYgLXVyIGEvbGliL0F1dG9tYWtlL0NvbmZpZy5pbiBiL2xpYi9BdXRvbWFrZS9Db25maWcu aW4KLS0tIGEvbGliL0F1dG9tYWtlL0NvbmZpZy5pbgkyMDIxLTA3LTEyIDA1OjQxOjEzLjAwMDAw MDAwMCArMDMwMAorKysgYi9saWIvQXV0b21ha2UvQ29uZmlnLmluCTIwMjUtMDMtMDEgMTc6Mjc6 MjkuMTQzMzgzNTQyICswMzAwCkBAIC0yMiwxMCArMjIsMTEgQEAKIHVzZSB3YXJuaW5ncyBGQVRB TCA9PiAnYWxsJzsKIAogdXNlIEV4cG9ydGVyOwordXNlIENvbmZpZzsKIAogb3VyIEBJU0EgPSBx dyAoRXhwb3J0ZXIpOwogb3VyIEBFWFBPUlQgPSBxdyAoJEFQSVZFUlNJT04gJFBBQ0tBR0UgJFBB Q0tBR0VfQlVHUkVQT1JUICRWRVJTSU9OCi0gICAgICAgICAgICAgICAgICAkUkVMRUFTRV9ZRUFS ICRsaWJkaXIgJHBlcmxfdGhyZWFkcyk7CisgICAgICAgICAgICAgICAgICAkUkVMRUFTRV9ZRUFS ICRkYXRhZGlyICRwYXRoX3NlcCAkcGVybF90aHJlYWRzKTsKIAogIyBQYXJhbWV0ZXJzIHNldCBi eSBjb25maWd1cmUuICBOb3QgdG8gYmUgY2hhbmdlZC4gIE5PVEU6IGFzc2lnbgogIyBWRVJTSU9O IGFzIHN0cmluZyBzbyB0aGF0IGUuZy4gdmVyc2lvbiAwLjMwIHdpbGwgcHJpbnQgY29ycmVjdGx5 LgpAQCAtMzQsMTMgKzM1LDEzIEBACiBvdXIgJFBBQ0tBR0VfQlVHUkVQT1JUID0gJ0BQQUNLQUdF X0JVR1JFUE9SVEAnOwogb3VyICRWRVJTSU9OID0gJ0BWRVJTSU9OQCc7CiBvdXIgJFJFTEVBU0Vf WUVBUiA9ICdAUkVMRUFTRV9ZRUFSQCc7Ci1vdXIgJGxpYmRpciA9ICRFTlZ7IkFVVE9NQUtFX0xJ QkRJUiJ9IHx8ICdAZGF0YWRpckAvQFBBQ0tBR0VALUBBUElWRVJTSU9OQCc7CitvdXIgJGRhdGFk aXIgPSAnQGRhdGFkaXJAJzsKK291ciAkcGF0aF9zZXAgPSAkQ29uZmlne3BhdGhfc2VwfTsKIAog b3VyICRwZXJsX3RocmVhZHMgPSAwOwogIyBXZSBuZWVkIGF0IGxlYXN0IHRoaXMgdmVyc2lvbiBm b3IgQ0xPTkUgc3VwcG9ydC4KIGlmIChldmFsIHsgcmVxdWlyZSA1LjAwN18wMDI7IH0pCiAgIHsK LSAgICB1c2UgQ29uZmlnOwogICAgICRwZXJsX3RocmVhZHMgPSAkQ29uZmlne3VzZWl0aHJlYWRz fTsKICAgfQogCmRpZmYgLXVyIGEvbGliL0F1dG9tYWtlL0ZpbGVVdGlscy5wbSBiL2xpYi9BdXRv bWFrZS9GaWxlVXRpbHMucG0KLS0tIGEvbGliL0F1dG9tYWtlL0ZpbGVVdGlscy5wbQkyMDIxLTA3 LTEyIDA1OjQxOjEzLjAwMDAwMDAwMCArMDMwMAorKysgYi9saWIvQXV0b21ha2UvRmlsZVV0aWxz LnBtCTIwMjUtMDMtMDEgMDA6MjQ6MjAuNjg5MDIwNjcwICswMzAwCkBAIC01NSw0NiArNTUsNDcg QEAKIAogPW92ZXIgNAogCi09aXRlbSBDPGZpbmRfZmlsZSAoJGZpbGVfbmFtZSwgQGluY2x1ZGUp PgorPWl0ZW0gQzxmaW5kX2ZpbGUgKCRmaWxlX25hbWUsIEBpbmNsdWRlLCB7b3B0aW9uYWwgPT4g JGJvb2x9KT4KIAogUmV0dXJuIHRoZSBmaXJzdCBwYXRoIGZvciBhIEM8JGZpbGVfbmFtZT4gaW4g dGhlIEM8aW5jbHVkZT5zLgogCi1XZSBtYXRjaCBleGFjdGx5IHRoZSBiZWhhdmlvciBvZiBHTlUg TTQ6IGZpcnN0IGxvb2sgaW4gdGhlIGN1cnJlbnQKLWRpcmVjdG9yeSAod2hpY2ggaW5jbHVkZXMg dGhlIGNhc2Ugb2YgYWJzb2x1dGUgZmlsZSBuYW1lcyksIGFuZCB0aGVuLAotaWYgdGhlIGZpbGUg bmFtZSBpcyBub3QgYWJzb2x1dGUsIGxvb2sgaW4gQzxAaW5jbHVkZT4uCitUaGUgZnVuY3Rpb24g ZG9lcyBub3QgdHJlYXQgdGhlIGN1cnJlbnQgZGlyZWN0b3J5IHNwZWNpYWxseToKK2lmIHlvdSB3 YW50IHRvIGxvb2sgZm9yIHRoZSBmaWxlIGluIHRoZSBjdXJyZW50IGRpcmVjdG9yeSwKK2luY2x1 ZGUgaXQgdG8gdGhlIEBpbmNsdWRlIGxpc3QuCiAKLUlmIHRoZSBmaWxlIGlzIGZsYWdnZWQgYXMg b3B0aW9uYWwgKGVuZHMgd2l0aCBDPD8+KSwgdGhlbiByZXR1cm4gdW5kZWYKK0lmIHRoZSBmaWxl IGlzIGZsYWdnZWQgYXMgb3B0aW9uYWwsIHRoZW4gcmV0dXJuIHVuZGVmCiBpZiBhYnNlbnQsIG90 aGVyd2lzZSBleGl0IHdpdGggZXJyb3IuCiAKID1jdXQKIAogIyAkRklMRV9OQU1FCi0jIGZpbmRf ZmlsZSAoJEZJTEVfTkFNRSwgQElOQ0xVREUpCisjIGZpbmRfZmlsZSAoJEZJTEVfTkFNRSwgQElO Q0xVREUsIHtvcHRpb25hbCA9PiAkQk9PTH0pCiAjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCiBzdWIgZmluZF9maWxlICgkQCkKIHsKICAgdXNlIEZpbGU6OlNwZWM7CiAKKyAgIyBJ ZiB0aGUgbGFzdCBhcmd1bWVudCBpcyBoYXNocmVmLCB1c2UgaXQgYXMgb3B0aW9ucy4KKyAgbXkg JW9wdHMgPSBAXyA+IDEgJiYgcmVmKCRfWy0xXSkgZXEgJ0hBU0gnID8gJXtwb3AoQF8pfSA6ICgp OwogICBteSAoJGZpbGVfbmFtZSwgQGluY2x1ZGUpID0gQF87Ci0gIG15ICRvcHRpb25hbCA9IDA7 CiAKLSAgJG9wdGlvbmFsID0gMQotICAgIGlmICRmaWxlX25hbWUgPX4gcy9cPyQvLzsKLQotICBy ZXR1cm4gRmlsZTo6U3BlYy0+Y2Fub25wYXRoICgkZmlsZV9uYW1lKQotICAgIGlmIC1lICRmaWxl X25hbWU7Ci0KLSAgaWYgKCFGaWxlOjpTcGVjLT5maWxlX25hbWVfaXNfYWJzb2x1dGUgKCRmaWxl X25hbWUpKQorICBpZiAoRmlsZTo6U3BlYy0+ZmlsZV9uYW1lX2lzX2Fic29sdXRlICgkZmlsZV9u YW1lKSkKKyAgICB7CisgICAgICByZXR1cm4gRmlsZTo6U3BlYy0+Y2Fub25wYXRoICgkZmlsZV9u YW1lKQorICAgICAgICBpZiAtZSAkZmlsZV9uYW1lOworICAgIH0KKyAgZWxzZQogICAgIHsKLSAg ICAgIGZvcmVhY2ggbXkgJHBhdGggKEBpbmNsdWRlKQorICAgICAgZm9yZWFjaCBteSAkZGlyIChA aW5jbHVkZSkKIAl7Ci0JICByZXR1cm4gRmlsZTo6U3BlYy0+Y2Fub25wYXRoIChGaWxlOjpTcGVj LT5jYXRmaWxlICgkcGF0aCwgJGZpbGVfbmFtZSkpCi0JICAgIGlmIC1lIEZpbGU6OlNwZWMtPmNh dGZpbGUgKCRwYXRoLCAkZmlsZV9uYW1lKQorICAgICAgICAgIG15ICRwYXRoID0gRmlsZTo6U3Bl Yy0+Y2F0ZmlsZSAoJGRpciwgJGZpbGVfbmFtZSk7CisJICByZXR1cm4gRmlsZTo6U3BlYy0+Y2Fu b25wYXRoICgkcGF0aCkKKwkgICAgaWYgLWUgJHBhdGg7CiAJfQogICAgIH0KIAogICBmYXRhbCAi JGZpbGVfbmFtZTogbm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSIKLSAgICB1bmxlc3MgJG9wdGlv bmFsOworICAgIHVubGVzcyAkb3B0c3tvcHRpb25hbH07CiAgIHJldHVybiB1bmRlZjsKIH0KIAo= --=-MYh/6pbnU7pq4lV8YVns-- From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. References: <9ec7c3e2dd374b115685fbd88107b16d98afc039.camel@yandex.ru> Resent-From: Karl Berry Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 10 Apr 2025 22:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59099 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: van.de.bugger@ya.ru Cc: 59099@debbugs.gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.174432527910958 (code B ref -1); Thu, 10 Apr 2025 22:48:01 +0000 Received: (at submit) by debbugs.gnu.org; 10 Apr 2025 22:47:59 +0000 Received: from localhost ([127.0.0.1]:47496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u30gg-0002qg-Ul for submit@debbugs.gnu.org; Thu, 10 Apr 2025 18:47:59 -0400 Received: from lists.gnu.org ([2001:470:142::17]:46556) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u30ge-0002qO-Vo for submit@debbugs.gnu.org; Thu, 10 Apr 2025 18:47:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u30gY-0001Vv-BX for bug-automake@gnu.org; Thu, 10 Apr 2025 18:47:50 -0400 Received: from frenzy.freefriends.org ([198.99.81.75] helo=freefriends.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u30gW-0001cy-LS for bug-automake@gnu.org; Thu, 10 Apr 2025 18:47:50 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 53AMlk8A553157 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 10 Apr 2025 16:47:46 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 53AMljFr553156; Thu, 10 Apr 2025 16:47:45 -0600 Date: Thu, 10 Apr 2025 16:47:45 -0600 Message-Id: <202504102247.53AMljFr553156@freefriends.org> From: Karl Berry In-Reply-To: <09e4c245ac95be8b64bfb74540f9ece96ec724a6.camel@ya.ru> Received-SPF: pass client-ip=198.99.81.75; envelope-from=karl@freefriends.org; helo=freefriends.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. Resent-From: Van de Bugger Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 15 Apr 2025 09:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59099 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry Cc: 59099@debbugs.gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.174470772414323 (code B ref -1); Tue, 15 Apr 2025 09:03:02 +0000 Received: (at submit) by debbugs.gnu.org; 15 Apr 2025 09:02:04 +0000 Received: from localhost ([127.0.0.1]:50609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u4cB8-0003iu-Vt for submit@debbugs.gnu.org; Tue, 15 Apr 2025 05:02:04 -0400 Received: from lists.gnu.org ([2001:470:142::17]:35516) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u4bnO-0002UZ-TM for submit@debbugs.gnu.org; Tue, 15 Apr 2025 04:37:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u4bnG-0002Y5-Sf for bug-automake@gnu.org; Tue, 15 Apr 2025 04:37:23 -0400 Received: from forward100b.mail.yandex.net ([178.154.239.147]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u4bnD-0005OL-VV for bug-automake@gnu.org; Tue, 15 Apr 2025 04:37:22 -0400 Received: from mail-nwsmtp-smtp-production-main-67.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-67.sas.yp-c.yandex.net [IPv6:2a02:6b8:c11:4ab1:0:640:c3ad:0]) by forward100b.mail.yandex.net (Yandex) with ESMTPS id 495D160D09; Tue, 15 Apr 2025 11:37:12 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-67.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id BbCMWDALgSw0-nBeXqv9h; Tue, 15 Apr 2025 11:37:11 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1744706231; bh=xADBTDKwu+bqjl5dBumXA9u79PCD5O7pmrKoCW1r2WQ=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=mtZrxByXVLW0yc2tOJ4p9YdbxbT81rgP9PpNGQVnFJT0K5c+qPbc50uYe6e03uyOB AdrzDyruYvsAGjVskToOythp+Fq00QU4OKZxN/3Du7zji+DHUj/U1Z74a34orRUxkS XZAXv53SOsG0EIsYU0yeXY8WuUPLARZhJI+Y0p5s= Authentication-Results: mail-nwsmtp-smtp-production-main-67.sas.yp-c.yandex.net; dkim=pass header.i=@ya.ru Message-ID: <137a6ee8ed208a72ef596d14b33d0871e7d997e3.camel@ya.ru> From: Van de Bugger Date: Tue, 15 Apr 2025 11:37:11 +0300 In-Reply-To: <202504102247.53AMljFr553156@freefriends.org> References: <202504102247.53AMljFr553156@freefriends.org> Content-Type: text/markdown; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 Received-SPF: pass client-ip=178.154.239.147; envelope-from=van.de.bugger@ya.ru; helo=forward100b.mail.yandex.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Mailman-Approved-At: Tue, 15 Apr 2025 05:02:01 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 2. find_file =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 pre= fer to rename the original function to find_file_m4, since it is more specializ= ed, while find_file_with_opt is more generic. 2a. find_file description =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Look, the last argument *was* described: =3Ditem C $bool})> ... find_file ($FILE_NAME, @INCLUDE, {optional =3D> $BOOL}) -------------------------------- Do you think it is not obvious enough? 3. Disclaimer =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It is the most complicated item. Original behaviour ------------------ 1. Search in the dir specified by the --libdir option, if the option is gi= ven. 2. If --libdir is not given, search in the dir specified by the=20 AUTOMAKE_LIBDIR env var, if the var exists. 3. If --libdir is not given and the AUTOMAKE_LIBDIR var does not exist, se= arch=20 in the default directory @datadir@/@PACKAGE@-@APIVERSION@. Note: The search for a file is performen only in the first specified direct= ory, searching never continues in the next directory. If someone wants to specify custom directory with AUTOMAKE_LIBDIR or --libd= ir, 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 Automak= e 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=20 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 n= ext 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, se= arch in the standard directory. I see only two potential issues: 1. The search continues in the next directory if the requested file is not= =20 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 work= s, 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 wou= ld specify multiple --libdir options, and why? By the way, the second issue can be easily fixed by adding directories to t= he 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 c= ase 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 shoul= d 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: >=20 > 1. Changing the meaning of the --libdir option so that it adds rather = =20 > than replaces. We have no way of knowing if existing projects rely on = =20 > that, but it's quite possible. A new option name is needed to avoid =20 > breaking compatibility. Since you don't like --libdirs (neither do I), = =20 > maybe --add-libdir. (The new --print-libdir[s] is ok, since that won't = =20 > change existing behavior, i.e., if the new "libdir list" functionality = =20 > is not used, the output will be the same. As I understand it.) >=20 > 2. Although Automake does not use the find_file function, autom4te (in = =20 > autoconf) does. Right now the Automake and Autom4te FileUtils.pm are =20 > kept in sync (by make fetch in autoconf), as far as I can see. Thus we = =20 > cannot change the behavior of find_file. Instead, a new function name is = =20 > needed, e.g., find_file_no_cwd or find_file_with_opt. >=20 > 2a. Also, the new description in the FileUtils.pm change does not =20 > mention the new final argument, or what the possible options can be.=C2= =A0 (I =20 > can tell from the code, I think, but it should be in the comment for the = =20 > function.) >=20 > 3. In order to install any patch, I need to ask you to sign a copyright = =20 > disclaimer or assignment. I hope that's ok. I'll send you that form =20 > separately. >=20 > Thanks again, =20 > Karl From unknown Sat Sep 13 08:57:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59099: 3-rd party aux files. References: <9ec7c3e2dd374b115685fbd88107b16d98afc039.camel@yandex.ru> Resent-From: Karl Berry Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 16 Apr 2025 20:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59099 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: van.de.bugger@ya.ru Cc: 59099@debbugs.gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.174483701131052 (code B ref -1); Wed, 16 Apr 2025 20:57:01 +0000 Received: (at submit) by debbugs.gnu.org; 16 Apr 2025 20:56:51 +0000 Received: from localhost ([127.0.0.1]:43208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u59oQ-00084m-E0 for submit@debbugs.gnu.org; Wed, 16 Apr 2025 16:56:50 -0400 Received: from lists.gnu.org ([2001:470:142::17]:53658) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u59oM-00083w-Kd for submit@debbugs.gnu.org; Wed, 16 Apr 2025 16:56:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u59oG-0000b7-Lg for bug-automake@gnu.org; Wed, 16 Apr 2025 16:56:40 -0400 Received: from frenzy.freefriends.org ([198.99.81.75] helo=freefriends.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u59oE-0002Jw-Bf for bug-automake@gnu.org; Wed, 16 Apr 2025 16:56:40 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 53GKua4F1140351 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Apr 2025 14:56:36 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 53GKuY851140350; Wed, 16 Apr 2025 14:56:34 -0600 Date: Wed, 16 Apr 2025 14:56:34 -0600 Message-Id: <202504162056.53GKuY851140350@freefriends.org> From: Karl Berry In-Reply-To: <137a6ee8ed208a72ef596d14b33d0871e7d997e3.camel@ya.ru> Received-SPF: pass client-ip=198.99.81.75; envelope-from=karl@freefriends.org; helo=freefriends.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 /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.