Automake conditionals were originally created because make conditionals aren't
portable. In principle, if you are willing to require GNU make (or any other
specific Make that has conditionals) you shouldn't *need* Automake conditionals.
Of course, things may not be that simple anymore. Can you p
On Tue, Jan 30, 2024, at 6:32 PM, Karl Berry wrote:
> test "$[*]" != "X conftest.ts1 conftest.ts2" ||
> ..
> test "$[]2" = conftest.ts3 &&
> ..
> etc.
>
> I've never seen anything like that before.
Oh! Those square brackets are M4 quotes to prevent M4 from expanding $* and $2
itself.
zw
On Tue, Jan 30, 2024, at 7:46 AM, Erik A Johnson wrote:
> I found the problem! The default GNU make on macOS (even Sonoma) is
> 3.81 from 2006! The configure script for GNU make versions <4.0 did
> not have the right test for subsecond resolution in the macOS stat()
> function, so 3.81 was built
On Mon, Jan 29, 2024, at 6:00 PM, Karl Berry wrote:
> But, looking at that code, I belatedly see that shell arrays are being
> used. At least I think so.
It is absolutely not *supposed* to be using shell arrays. If it is, that was a
mistake on my part.
zw
On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
> On 13 Jan 2024 15:58, Karl Berry wrote:
>> Another alternative: when this came up 30-odd years ago, rms changed the
>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>> that would at least have the benefit of following
On Sat, Dec 2, 2023, at 9:08 PM, Mike Frysinger wrote:
> On 02 Dec 2023 15:53, Karl Berry wrote:
>> Exit status yes, but at least historically, grep -q has been
>> considered non-portable, in favor of grep ... >/dev/null.
>
> i get that `grep -q` is something historically we've avoided, but i
> thi
On Mon, Jul 31, 2023, at 1:39 PM, Zack Weinberg wrote:
> On Mon, Jul 31, 2023, at 2:02 AM, 874882199--- via Bug reports for
> Automake wrote:
>> In Docker(in the vmware ubunt also has the problem):
>> Environment:
>> Ubuntu 20.04 5.15.0-78-generic.
>> Automake1.4 f
On Mon, Jul 31, 2023, at 2:02 AM, 874882199--- via Bug reports for Automake
wrote:
> In Docker(in the vmware ubunt also has the problem):
> Environment:
> Ubuntu 20.04 5.15.0-78-generic.
> Automake1.4 from ftp://gcc.gnu.org/pub/java/automake-gcj-1.4.tar.gz.
This is a very old version of automake.
On Mon, Apr 24, 2023, at 5:46 AM, Travis Goff wrote:
> /kalibrate-rtl$ bash /usr/share/automake-1.16/missing --help
> [... help output ...]
Could you please explain what went wrong here? Be as specific as possible. What
do you think happened, and what do you think should having happened instead?
On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake
wrote:
> On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger wrote:
> No, I don't have one. It just crossed my eyes while working on more
> silent rules in Automake. I made Ben recently aware of these changes,
> which are avail
On Sat, Sep 24, 2022, at 5:45 AM, Richard Hopkins wrote:
> On 2022-09-23 16:15, Zack Weinberg wrote:
>> Thank you for the patch. Are you able to test it with a version of
>> GNU Emacs older than 23.2? I see that you tested it with XEmacs 21,
>> but as I recall there w
On Fri, Sep 23, 2022, at 8:24 AM, em...@unbit.co.uk wrote:
> The attached `git format-patch` is based on automake v1.16.5 and fixes
> the following warning
>
> Warning (bytecomp): byte-compile-dest-file is obsolete (as of 23.2);
> Set byte-compile-dest-file-function instead.
>
> The solut
> i'm inclined to bring this back as the way to opt-in to silent-rules
> by default.
And I’m still absolutely opposed to making it even *possible* to have silent
rules be on by default. In fact I’d like to see —enable-silent-rules removed,
with make V=0 the *only* way to switch to silent mode.
On Wed, Jan 26, 2022, at 6:37 AM, Mike Frysinger wrote:
> Fixes automake bug https://bugs.gnu.org/53530.
>
> Based on the cadence of Automake releases, add the current Python
> release (3.10), the current Python development (3.11), and then 4
> more versions on top of that. It doesn't hurt to chec
On Sat, Jan 22, 2022, at 4:44 PM, Karl Berry wrote:
> Sorry, I still disagree with "deprecating" AM_WITH_DMALLOC (or anything
> else). My wish would be to add some strong wording in the manual about
> how it doesn't do anything especially useful, new code shouldn't use it,
> etc., and let it go at
On Wed, Sep 8, 2021, at 1:31 AM, Akim Demaille wrote:
> One big problem with the Autotools as of today is that they promote
> the use of macros/build rules for Yacc, not for Bison.
The contract of AC_PROG_YACC is to find something that will generate
parsers from POSIX-compliant input; all three of
It looks like this didn't go through to bug-automake because the bug
was still considered to be assigned to autoconf at the time.
-- Forwarded message -
From: Zack Weinberg
Date: Fri, Sep 4, 2020 at 9:44 AM
Subject: Re: bug#14196: Problem with invoking "missing" in
, I have a minor question:
Zack, are you the same "Zack Weinberg" already listed in the THANKS file
with the address "z...@codesourcery.com"? If yes, should I update that
address?
Yes I am, and yes you should update that address. I left CodeSourcery
in 2005, but I mean z
If you use AM_MAINTAINER_MODE([enable]), configure will print
> checking whether to disable maintainer-specific portions of Makefiles ... yes
when --disable-maintainer-mode was *not* given on the command line, and
> checking whether to disable maintainer-specific portions of Makefiles ... no
wh
19 matches
Mail list logo
