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

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 following

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

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

ill do that 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 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

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

[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

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

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

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

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

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 defa

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: [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

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

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

[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

[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 purpose of the pa

[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

[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

[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

[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

[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#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

[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#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

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

[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#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

[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

[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

[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

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