[bug#71672] [PATCH] python: Prefer python3 over python

On Mon, Feb 24, 2025, at 11:48 AM, Karl Berry wrote: > Returning to this issue of preferring python3, from last year: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71672 > > Add these three macros to Autoconf proper: ..._PYTHON_... > > Have they been added? They have not. Regrettably,

[bug#71672] [PATCH] python: Prefer python3 over python

On Mon, Feb 24, 2025, at 11:03 PM, Jacob Bachmeyer wrote: > On 2/24/25 10:48, Karl Berry wrote: >> [...] >> >> To be clear, the above suggested factoring-out won't (intentionally) >> affect the behavior of AM_PATH_PYTHON, right? It will still look for >> "python" first, and still do all the stuff i

[bug#72225] [PATCH] _AM_PROG_CC_C_O: clean up after .dSYM directories properly

On Sun, Jul 21, 2024, at 5:20 AM, Eric Gallager via Patches for Automake wrote: > On darwin, the compiler will generate .dSYM directories (for debug > info) alongside executables when invoked, leading to messages like the > following in configure output: > > checking whether /usr/local/bin/gcc unde

[bug#71672] [PATCH] python: Prefer python3 over python

Here's what I think might be useful: Add these three macros to Autoconf proper: # AC_PYTHON_VERSION_RANGE_IFELSE([PROG], [MIN-VERSION], [MAX-VERSION = next-major], #[ACTION-IF-TRUE], [ACTION-IF-FALSE]) # - # Run

[bug#71672] [PATCH] python: Prefer python3 over python

On Thu, Jun 20, 2024, at 5:50 AM, Collin Funk wrote: > Shouldn't AM_PATH_PYTHON check for the python3 command before python? Yes it should. > The full recommendation of how these should be setup is in PEP 394 Note that PEP 394 is dangerously incorrect on one point: a system where /usr/bin/python

[bug#71534] [PATCH] aclocal: support ACLOCAL_PATH correctly on OS/2

On Thu, Jun 13, 2024, at 5:44 PM, Karl Berry wrote: > + my $sep = $^O eq 'os2' ? ';' : ':'; > + foreach my $dir (reverse split /$sep/, $ENV{"ACLOCAL_PATH"}) > > Ok, thanks. > > If we're going to worry about os2, then surely $O =~ /MSWin/ should also > be ;-separated paths Isn't there a $vari

[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list

On Mon, Jan 15, 2024, at 7:02 PM, Jacob Bachmeyer wrote: > Frederic Berat wrote: >> pythons="python python2 python3" >> for i in {20..0};do pythons="$pythons python3.$i";done >> for i in {7..0};do pythons="$pythons python2.$i";done >> >> m4_define_default([_AM_PYTHON_INTERPRETER_LIST], [$pythons])

[bug#68325] sanity.m4: a millisecond is too fast?

On Mon, Jan 8, 2024, at 7:44 AM, Karl Berry wrote: > The plethora of bug reports from the last pretest make me believe that > many systems simply cannot (currently) reliably handle a millisecond > difference in mtime. ... > My current idea is to only try for a hundredth of a second. ... > The whole

[bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

On Sat, Dec 23, 2023, at 1:54 PM, > Without Jacob's suggested use of encode(), I see (Jacob, thanks for the > explanations), but Zack, I'm not sure you intended this bug to track > that. Feel free to reopen if so. I decided I didn't want to write that code and verify it in a hurry. I'll come bac

[bug#67971] [PATCH] Sync shared files from Autoconf

lib/Automake/ChannelDefs.pm and lib/Automake/Channels.pm were updated in Autoconf to address . Bring over the changes. It *should* be impossible to reach report_bad_channel from code in Automake. * lib/Automake/Channels.pm (msg): If the channel argument i

[bug#67841] [PATCH v2, committed] Clarify error messages for misuse of m4_warn and --help for -W.

m4_warn([category], [message]) passes its arguments directly to Autom4te::Channels::msg. If the category argument is not a recognized “channel”, that function will crash and emit a *Perl* stack trace, which makes it look like there’s something wrong with autoconf or autom4te, rather than something

[bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

On Fri, Dec 15, 2023, at 6:52 PM, Karl Berry wrote: > Hi Zack, > > Since this touches code shared between Autoconf and Automake, I'm not > checking it in yet and I'm requesting comments from both sides of the > fence. > > Well, it seems good to me in principle, FWIW. I don't think this

[bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

On Fri, Dec 15, 2023, at 7:08 PM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: >> [...] >> Also, there’s a perl 2.14ism in one place (s///a) which I need >> to figure out how to make 2.6-compatible before it can land. ... >> + $q_channel =~ s/([^\x20-\x7e])/"\

[bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

In autoconf 2.69, the manual said that you could use “all” and the empty string as the first argument to m4_warn. As far as I can tell this was never actually true, and the manual was corrected in 2.70, but we still got a bug report from someone who tried it and got a confusing internal error from

[bug#67670] [PATCH] Revise tests for file mtime resolution again.

In order for the Automake testsuite to be able to use sub-second delays to control whether certain files are considered newer than others, five(!) separate pieces of software all need to cooperate: automake itself, autoconf’s internal “autom4te” utility, the Perl interpreter and its libraries, the

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

> Karl Berry , Fri Sep 01 2023 00:28:04 GMT+0200 > (Central European Summer Time) >> Bogdan: I will adjust the patch, one way or another. Nothing more for >> you to do here after all :). --thanks, karl. Karl: The same problem was also reported as bug 65730, with a patch supplied by Łukasz Stelmach

[bug#60807] [PATCH v2] tests: reuse am_cv_filesystem_timestamp_resolution

On Sat, Jan 14, 2023, at 7:18 PM, Mike Frysinger wrote: > Rather than assume such coarse delays, re-use existing logic for > probing the current filesystem resolution. This speeds up the > testsuite significantly. On my system, it speeds -j1 up quite a > lot -- by ~30%. While I didn't gather man

[bug#59994] [PATCH] tests: Don't try to prevent flex to include unistd.h

On Fri, Jan 13, 2023, at 6:33 PM, Karl Berry wrote: >> your patch *and* consistently test flex with "--never-interactive". > > Making flex non-interactive sounds desirable in any case, but > --never-interactive is not mentioned in the 2.6.0 --help message. > Instead there is -B (--batch), although

[bug#60535] [PATCH] depend2: switch echo|sed to automatic vars

On Thu, Jan 5, 2023, at 6:47 PM, Karl Berry wrote: > Please excuse my curmudgeonness, but it's not clear to me that avoiding > sed is worth these hassles in working around the implementation-specific > bugs in the automatic variables. It seems to me that this would be worth doing *if* we could get

[bug#59993] [PATCH 2/2] tests: Fix implicit function declaration errors

On Thu, 15 Dec 2022 11:48:44 -0500, Frederic Berat wrote: > On Mon, Dec 12, 2022 at 9:19 PM Zack Weinberg wrote: > > > return yylex (); > > Please change `int main ()` to `int main (void)` as long as you're in here. > I'm hesitant on this. That isn't the pu

[bug#59992] [PATCH 1/2] tests: Fix 'type defaults' error in link_cond due to main not being properly declared

On Thu, Dec 15, 2022, at 2:12 AM, Frederic Berat wrote: > For the record: > > cat > less.c <<'END' > /* Valid C but deliberately invalid C++ */ > int main (void) > { > int new = 0; > return new; > } > END > > $> g++ less.c > less.c: In function ‘int main()’: > less.c:4:7: error: expected unqual

[bug#59993] [PATCH 2/2] tests: Fix implicit function declaration errors

On Tue, Dec 13, 2022, at 1:30 AM, Frederic Berat wrote: > On Mon, Dec 12, 2022 at 9:19 PM Zack Weinberg wrote: >> > --- a/t/ax/depcomp.sh >> > +++ b/t/ax/depcomp.sh >> > @@ -243,6 +243,7 @@ cat > sub/subfoo.h <<'END' >> > #include

[bug#59991] [PATCH 0/2] Port tests to modern C

On Mon, Dec 12, 2022, at 5:57 PM, Karl Berry wrote: > Zack, would you like be co-maintainer or at least co-developer of > Automake? There is, evidently, no one else in the world interested in > being actively involved with Automake on the maintainer side. I have to decline; I don't have anything l

[bug#59994] [PATCH] tests: Don't try to prevent flex to include unistd.h

On 2022-12-12 2:07 AM, Frederic Berat wrote: This patch is mainly a proposal. While the macro can simply be removed as explained below, another possibility it to add a flex option "--never-interactive" to prevent flex to make use of "isatty". This is related to an effort to prepare Automake for

[bug#59993] [PATCH 2/2] tests: Fix implicit function declaration errors

On 2022-12-12 2:05 AM, Frederic Berat wrote: This is related to an effort to prepare Automake for future GCC/Clang versions which set c99 as default standard to be used. Function should be properly declared prior to use in order to be compatible with c99 standard. OK in principle, but ... ---

[bug#59992] [PATCH 1/2] tests: Fix 'type defaults' error in link_cond due to main not being properly declared

On 2022-12-12 2:05 AM, Frederic Berat wrote: This is related to an effort to prepare Automake for future GCC/Clang versions which set c99 as default standard to be used. Not properly declaring main as "int main(...)" is rejected since c99. ... /* Valid C but deliberately invalid C++ */ -main

Re: [PATCH] python: prioritize python 3.x over 2.x

On Thu, Jan 27, 2022, at 9:20 PM, Jacob Bachmeyer wrote: >> Now, nobody listens to me, and I'm painfully aware that "python" >> pointing to Python 3 is common, but that doesn't mean Autotools should >> make the situation even worse. Autotools should, on its own motion, >> discourage the use of "py

Re: [PATCH] python: prioritize python 3.x over 2.x

On Wed, Jan 26, 2022, at 10:10 PM, Mike Frysinger wrote: > On 26 Jan 2022 10:07, Zack Weinberg wrote: >> Please also move the plain "python" command down to the python2 >> block (right after "python2" would be the best place I think). Any >> system o

Re: [PATCH] python: prioritize python 3.x over 2.x

On Wed, Jan 26, 2022, at 10:07 AM, Zack Weinberg wrote: > On Wed, Jan 26, 2022, at 6:37 AM, Mike Frysinger wrote: >> Since Python 2.x went EOL years ago, stop searching for it before >> any of the Python 3 versions. > > +1 It occurred to me right after pushing "send&q

Re: [PATCH] python: prioritize python 3.x over 2.x

On Wed, Jan 26, 2022, at 6:37 AM, Mike Frysinger wrote: > Since Python 2.x went EOL years ago, stop searching for it before > any of the Python 3 versions. +1 >m4_define_default([_AM_PYTHON_INTERPRETER_LIST], > -[python python2 python3 dnl > +[python python3 dnl > python3.15 python3.14 pyth

Re: [PATCH 1/2] m4: warn when AM_SILENT_RULES default is used

On Sun, Dec 12, 2021, at 1:09 AM, Mike Frysinger wrote: > To help ease people into enabling silent rules by default, warn if > a package doesn't make an explicit selection. -1 for the same reason that changing the default is a bad idea. If we are to make *any* change in this area I would advocate

Re: [RFC/PATCH] m4: enable silent build rules by default

On Sun, Dec 12, 2021, at 1:10 AM, Mike Frysinger wrote: > On 07 Dec 2021 21:58, Zack Weinberg wrote: >> On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote: >> > This has been available since automake 1.11 released over a decade >> > ago. Let's flip the de

Re: [PATCH] gitignore: update

On Sun, Dec 12, 2021, at 1:07 AM, Mike Frysinger wrote: > Ignore all *~ files as editors like to create them, as do some > autotool steps. This also matches what autoconf is doing. ... > +*~ > +.#* Suggest also adding \#*# (emacs autosave files) and .*.sw[op] (vim autosave files). zw

Re: [RFC/PATCH] m4: enable silent build rules by default

On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote: > This has been available since automake 1.11 released over a decade > ago. Let's flip the default to enable silent builds by default. Please don't *ever* make this change. It is absolutely essential that the default build output be verbose

Re: [PATCH] dist: add new "pure-dist" automake option

On Fri, Jul 2, 2021 at 11:09 AM Allison Karlitskaya wrote: > > Since v1.15.1-204-gac47c22e3, "make dist" has been depending on > $(BUILT_SOURCES) to avoid problems when building some GNU packages which > need to compile themselves as part of building their tarballs (for > example, to generate manp

Re: [PATCH] Add --jobserver/jobserver option for GCC -flto=jobserver

On Wed, Oct 28, 2020 at 4:00 PM H.J. Lu wrote: > On Wed, Oct 28, 2020 at 11:40 AM Nick Bowler wrote: > > On 2020-10-28, Zack Weinberg wrote: > > > On Wed, Oct 28, 2020 at 2:16 PM Nick Bowler wrote: > > >> On 2020-10-28, H.J. Lu wrote: > > >> &

Re: [PATCH] Add --jobserver/jobserver option for GCC -flto=jobserver

On Wed, Oct 28, 2020 at 2:16 PM Nick Bowler wrote: > On 2020-10-28, H.J. Lu wrote: > > GCC introduced some time ago option -flto=jobserver in order to use the > > GNU Make jobserver when parallelising LTO builds. It is actually a > > similar "recursive make". When doing a recursive make, you ne

[RFC PATCH 1/3] New utility function Automake::ChannelDefs::merge_WARNINGS.

This function merges a list of warnings categories into the environment variable WARNINGS, returning a new value to set it to. The intended use is in code of the form { local $ENV{WARNINGS} = merge_WARNINGS ("this", "that"); # run a command here with WARNINGS=this,that,etc } This is not act

[RFC PATCH 3/3] Update documentation of warnings options and strictness levels.

The warning categories ‘cross’ and ‘portability-recursive’ were not mentioned in the manual. Also clarify the relationship between warnings categories and strictness levels, and streamline the description of strictness levels by merging the “Gnits” section into the “Strictness” section. * doc/aut

[RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

org/archive/html/autoconf-patches/2020-09/msg8.html> for the rationale for merge_WARNINGS, which is not used in automake, but will be in autoconf. Zack Weinberg (3): New utility function Automake::ChannelDefs::merge_WARNINGS. Use WARNINGS=none to suppress warnings from autom4te runs.

[RFC PATCH 2/3] Use WARNINGS=none to suppress warnings from autom4te runs.

aclocal uses autom4te in trace mode to scan configure.ac for macros whose definition is not yet available. It has a kludge to prevent this from producing spurious warnings, but a cleaner, fully backward compatible, way to get the same effect is to set WARNINGS=none in the environment and not pass

[RFC PATCH 3/6] Disable all warnings when running autoconf as a subprocess.

autoheader and autoscan both run autoconf in trace mode, and autoheader makes a point of passing down the warnings options. This means autoheader prints warnings that a regular invocation of autoconf would also print, so in the common case where both are being run by autoreconf, the warnings are du

[RFC PATCH 6/6] Autoupdate AC_{DIAGNOSE, FATAL, OBSOLETE, WARNING} and _AC_COMPUTE_INT.

While working on the previous patches I noticed that all of these macros are officially obsolete, but autoupdate doesn’t replace them. _AC_COMPUTE_INT is easy to autoupdate. AC_{DIAGNOSE,FATAL,WARNING} require a little special handling because their replacements are m4sugar macros, and autoupdate

[RFC PATCH 1/6] Manually sync ChannelDefs.pm from automake.

ChannelDefs.pm *ought* to be kept in sync between automake and autoconf, because it defines the set of valid -W options, and autoreconf assumes that it can pass arbitrary -W options to all of the tools it invokes. However, it isn’t covered by either project’s ‘make fetch’ and it hasn’t actually *be

[RFC PATCH 2/6] New utility function Autom4te::ChannelDefs::merge_WARNINGS.

This function merges a list of warnings categories into the environment variable WARNINGS, returning a new value to set it to. The intended use is in code of the form { local $ENV{WARNINGS} = merge_WARNINGS ("this", "that"); # run a command here with WARNINGS=this,that,etc } This is not use

[RFC PATCH 0/6] Work around autoconf/automake warnings skew

t in a separate commit after all the dust settles from this patchset. zw -- Zack Weinberg (6): Manually sync ChannelDefs.pm from automake. New utility function Autom4te::ChannelDefs::merge_WARNINGS. Disable all warnings when running autoconf as a subprocess. Use WARNINGS to pass down warnings o

[RFC PATCH 5/6] Update documentation related to warnings.

This makes the Texinfo documentation consistent with the previous changes. --help output regarding warnings is already drawn directly from ChannelDefs.pm and thus does not need to be updated. * doc/autoconf.texi: Update all ‘invocation’ sections to describe -W/--warnings consistently, and to re

[RFC PATCH 4/6] Use WARNINGS to pass down warnings options from autoreconf.

autoreconf runs a bunch of subsidiary tools, and is expected to pass along various command-line settings, such as those controlling warnings. It has historically done this via the command line. However, not all of the tools recognize the same set of command-line warnings options. There’s an exist

[PATCH 4/4] t/python-virtualenv.sh: Skip when versions don’t match

On some operating systems ‘python’ is Python 2.x but ‘virtualenv -ppython’ will create a virtualenv that uses Python 3.x. This is a bug, but it’s not *automake’s* bug, and should not cause t/python-virtualenv.sh to fail. Skip the test, instead of failing it, when the inner=outer version check fail

[PATCH 3/4] Consistently use ‘our’ instead of ‘use vars’.

At file scope of a file containing at most one ‘package’ declaration, ‘use vars’ is exactly equivalent to ‘our’, and the latter is preferred starting with Perl 5.6.0, which happens to be the oldest version we support. (This change has nothing to do with the previous two, but I want to make the sam

[PATCH 2/4] Consistently process -W(no-)error after all other warning options.

automake and aclocal were processing ‘-W(no-)error’ whenever it appeared on the command line, which means that ‘-Werror,something-strange’ would issue a hard error, but ‘-Wsomething-strange,error’ would only issue a warning. It is not desirable for warnings about unknown warning categories ever to

[PATCH 0/4] Reduce warning category skew between automake and autoconf

o make the same change on autoconf’s side, so it needs to happen in the .pm files belonging to automake first. Patch 4 fixes a glitch in the testsuite that I noticed while testing the above changes. OK to commit? zw -- Zack Weinberg (4): Sync ChannelDefs.pm from autoconf. Consistently proc

[PATCH 1/4] Sync ChannelDefs.pm from autoconf.

ChannelDefs.pm *ought* to be kept in sync between automake and autoconf, because it defines the set of valid -W options, and autoreconf assumes that it can pass arbitrary -W options to all of the tools it invokes. However, it isn’t covered by either project’s ‘make fetch’ and it hasn’t actually *be

[PATCH] Use ‘use warnings’ instead of -w on #! lines.

Some downstream redistributors for Autoconf wish to use ‘/usr/bin/env perl’ as the #! line for the installed Perl scripts. This does not work with command-line options on the #! line, as the kernel doesn’t support supplying more than one argument to a #! interpreter (this limitation is universal ac

Re: [PATCH] Use ‘use warnings’ instea d of -w on #! lines.

On Mon, Aug 31, 2020 at 9:33 PM Karl Berry wrote: > I installed your patch without change. > make check and distcheck also worked for me afterward. > > I'll send you the usual assignment request separately. Thanks for the quick merge! I'm a bit surprised to learn I hadn't already filed a copyrig

[PATCH] Use ‘use warnings’ instead of -w on #! lines.

Some downstream redistributors for Autoconf wish to use ‘/usr/bin/env perl’ as the #! line for the installed Perl scripts. This does not work with command-line options on the #! line, as the kernel doesn’t support supplying more than one argument to a #! interpreter (this limitation is universal ac

Re: depcomp: support newer HP compilers

On Wed, Jan 04, 2006 at 12:23:44AM +0100, Ralf Wildenhues wrote: > > Do you have any idea which system might expose this? None of the > ones I have access to do, and it helps both for adding a note to > the Autoconf doc portability section, and assessing whether we > should check the autotools fo

Re: depcomp: support newer HP compilers

On Tue, Jan 03, 2006 at 01:01:52PM +0100, Ralf Wildenhues wrote: > Hi Zack, Alexandre, > > Sorry for a very late comment to this old thread; I now have access to > such a system. For myself, I have moved on and no longer have access to any HP systems, but it is good to hear that someone is follow

Re: depcomp: support newer HP compilers

Alexandre Duret-Lutz said: > Hi Zack, > > Sorry for the delay. No worries. However, I no longer work for CodeSourcery, and cannot test anything on HP boxen anymore. Also, I refuse to have anything to do with libtool. I'm afraid you're on your own for most of those fixes. > zw> HP's documentat

depcomp: support newer HP compilers

I discovered today that the newer HP compilers (for their ia64 systems) don't match any depcomp style. The preprocessor has been integrated into the compiler front end, so -Wp, is silently ignored. These systems don't ship 'makedepend', so that doesn't work either. And the last-resort "cpp" style