Paul Eggert writes:
> On 2/6/24 20:37, Nick Bowler wrote:
>> On 2024-02-06 22:33, Sam James wrote:
>>> Noticed when building Emacs:
>>> ```
>>> * checking type of array argument to getgroups... ./configure: 42782: test:
>>> =: unexpected operator
>>> ```
>
>> Oh look, I see this line in
Nick Bowler writes:
> On 2024-02-06 22:33, Sam James wrote:
>> Noticed when building Emacs:
>> ```
>> * checking type of array argument to getgroups... ./configure: 42782: test:
>> =: unexpected operator
>> ```
>> This turns out to be because of missing
On 2/6/24 20:37, Nick Bowler wrote:
On 2024-02-06 22:33, Sam James wrote:
Noticed when building Emacs:
```
* checking type of array argument to getgroups... ./configure: 42782: test: =:
unexpected operator
```
Oh look, I see this line in emacs-29.2/configure.ac:
On 2024-02-07 00:54, Nick Bowler wrote:
> On 2024-02-07 00:37, Paul Eggert wrote:
>> On 2024-02-06 20:37, Nick Bowler wrote:
>>> The right place to fix this problem is in Emacs.
>>
>> I don't see this problem in current (bleeding-edge Savannah) Emacs.
>> Sam, which Emacs are you talking about?
>
On 2024-02-07 00:37, Paul Eggert wrote:
> On 2024-02-06 20:37, Nick Bowler wrote:
>> The right place to fix this problem is in Emacs.
>
> I don't see this problem in current (bleeding-edge Savannah) Emacs.
> Sam, which Emacs are you talking about?
The issue is still present on emacs git master
On 2024-02-06 20:37, Nick Bowler wrote:
The right place to fix this problem is in Emacs.
I don't see this problem in current (bleeding-edge Savannah) Emacs. Sam,
which Emacs are you talking about?
On 2024-02-06 22:33, Sam James wrote:
> Noticed when building Emacs:
> ```
> * checking type of array argument to getgroups... ./configure: 42782: test:
> =: unexpected operator
> ```
> This turns out to be because of missing quotes in AS_IF for
> ac_cv_type_gid_t in AC_T
Noticed when building Emacs:
```
* checking type of array argument to getgroups... ./configure: 42782: test: =:
unexpected operator
```
This turns out to be because of missing quotes in AS_IF for ac_cv_type_gid_t
in AC_TYPE_GETGROUPS.
* lib/autoconf/types.m4 (AC_TYPE_GETGROUPS): Use quotes
On Mon, Oct 12, 2020 at 3:01 AM Paul Eggert wrote:
> On 10/6/20 5:52 PM, Zack Weinberg wrote:
> > I'm not sure we should say AS_IF/CASE
> > are equivalent to plain shell if/case inside an AC_DEFUN; they do do
> > more than just make the m4 expansion stack not be empty.
>
On 10/6/20 5:52 PM, Zack Weinberg wrote:
I agree that this should be clarified; I just had the same
conversation in another thread. I'm not sure we should say AS_IF/CASE
are equivalent to plain shell if/case inside an AC_DEFUN; they do do
more than just make the m4 expansion stack not be empty
evant, because required macros are hoisted
> > > before the body of the AC_DEFUN anyway.
...
> > But now that you mention it, AS_IF isn't needed here and I installed the
> > attached further patch. Also, to help prevent others from making a similar
> > mistake, I plan
gt; > before the body of the AC_DEFUN anyway.
>
> I was playing it safe based on this NEWS item from Autoconf 2.69c:
>
> - Autoconf macros that use AC_REQUIRE internally, are not safe to
> use inside of hand-written shell control-flow constructs. Use
> A
[adding autoconf-patches; replies can drop autoconf]
According to adso on 1/8/2010 5:48 AM:
maybe i am saying some none sense but
Have you check to don't leave any space between the name of the macro and
their arguments.
for example:
AS_IF ( fails for me but
AS_IF( it works
Ohh thank you for telling me. Sorry i read too fast the manual. I just
copied and pasted the AS_IF function from the pdf autoconf manual, and i
kept the space. Too lazy :)
I am Juan Carlos Hurtado to introduce myself to the list :).
Thank you very much.
On Fri, Jan 8, 2010 at 2:56 PM, Eric
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/14/2009 7:09 PM:
$ zsh -c 'emulate sh; false; $empty; echo $?'
1
Present in zsh 4.3.6, not present in zsh 4.3.4, BTW.
I'm still trying to figure out where best to document this in the manual.
Done as follows:
- --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/10/2009 11:00 AM:
According to Ralf Wildenhues on 4/9/2009 11:56 PM:
Can you hold back on this for a couple of days? I'm still in the
process of going through Automake testsuite results, and might have
found a tangent
m4_define([_AS_IF_ELSE],
[m4_ifnblank([$1],
[else
$1
])])
which puts the burden back on the user, where calling:
AS_IF([false], [], [AC_REQUIRE(...)])
causes a syntax error.
If I could get AC_REQUIRE to play nicely with m4_expand, then that would be the
solution - pre-expand the user's text
Eric Blake ebb9 at byu.net writes:
which puts the burden back on the user, where calling:
AS_IF([false], [], [AC_REQUIRE(...)])
causes a syntax error.
If I could get AC_REQUIRE to play nicely with m4_expand, then that would be
the
solution - pre-expand the user's text, at which
favorite; along with not promising that we avoid shell syntax
errors at all costs.
which puts the burden back on the user, where calling:
AS_IF([false], [], [AC_REQUIRE(...)])
causes a syntax error.
I think this is good enough. Such code is not written by very new
users, the error
...@byu.net
Date: Tue, 14 Apr 2009 19:06:27 -0600
Subject: [PATCH] Fix yesterday's regression in AS_IF.
* lib/m4sugar/m4sh.m4 (_AS_IF_ELSE): Don't corrupt $? in else
branch; the user has to avoid syntax errors.
* tests/m4sh.at (AS@t...@_if and AS@t...@_case): Adjust test.
Signed-off-by: Eric Blake e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 4/9/2009 11:56 PM:
Which pre-dates shell functions. Therefore, since AS_IF is part of m4sh,
which guarantees a shell with functions, can elide empty else statements
with impunity. Thanks for the research.
I'm
This would be a good time to eliminate the term hairy constructs
which is surely confusing to people for whom english is a second
language.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,
Bob Friesenhahn bfriesen at simple.dallas.tx.us writes:
This would be a good time to eliminate the term hairy constructs
which is surely confusing to people for whom english is a second
language.
Sure; I'll use 'lengthy' instead of 'hairy'.
According to Ralf Wildenhues on 4/9/2009 11:56
III shell.
Which pre-dates shell functions. Therefore, since AS_IF is part of m4sh,
which guarantees a shell with functions, can elide empty else statements
with impunity. Thanks for the research.
I'm thinking of applying this patch; any objections to the wording?
Can you hold back
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paolo Bonzini on 10/21/2008 8:36 PM:
I'll apply this tomorrow unless I get feedback first.
Seems a good idea...
Committed.
Commit the AC_PREPROC_IFELSE functionization too
already done earlier today, but I just now did 2/12
so
so that I'll rebase my other function patches (by the way, are you going
to frob all the other 11 patches 11, to split the function body, too?).
Yes, I've been (slowly) visiting them one at a time; we might as well be
consistent splitting out the function body.
Great -- take your time!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paolo Bonzini on 10/22/2008 6:20 AM:
so that I'll rebase my other function patches (by the way, are you going
to frob all the other 11 patches 11, to split the function body, too?).
Yes, I've been (slowly) visiting them one at a time;
I noticed that _AS_VAR_APPEND_PREPARE was ending in:
fi
# AS_VAR_APPEND
rather than the desired
fi # AS_VAR_APPEND
For that matter, it should be possible to do
AS_IF(...) ...
or even
AS_IF(...) file
similar to many of the other AS_ macros that intentionally do not add a newline
I'll apply this tomorrow unless I get feedback first.
Seems a good idea... Commit the AC_PREPROC_IFELSE functionization too
so that I'll rebase my other function patches (by the way, are you going
to frob all the other 11 patches 11, to split the function body, too?).
Paolo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 8/16/2008 3:02 AM:
Also, should it be named slightly differently since it behaves more
like m4_map than m4_foreach?
m4_map_pair maybe?
I went with the name m4_transform_pair, since it turned out to be very
easy to
At any rate, I'm interested in documenting these macros, as well as adding
a counterpart macro for m4_set iteration (the recent
_AS_DETECT_BETTER_SHELL change can be sped up). It turns out that m4 is
more efficient when you pass the list element as an argument to a macro
invocation than it
Makefile-triggered autotools reruns. The next question
is whether we should care, or decree that m4 is now fast enough. ;-)
But I agree that this is a good post-2.63 question.
Avoid timestamp races for updated input.
* tests/m4sh.at (AS_IF and AS_CASE): Use `autom4te --force
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:
Any help I can offer on tracking down the (unrelated) AS_IF failures?
Not sure. See below. I recently updated this system to Debian lenny, I
kind of think that may be one cause (or exposure reason).
Hmmm. This looks suspicious
are tripping some other shell
limits with my test enhancements last week, even though I scaled back the
limit
to 1000 instead of 2500. Maybe it was a mistake to add torture tests to the
already existing AS_IF test, instead of creating a new test?
Ahh, thanks for this hint. It is indeed
this messes up some internal shell
data.
Maybe we should relax that test?
Sure. This scales AS_IF back by a factor of 10, then stresses
m4_transform separately.
Thanks. Weirdly, the failure still happens. It even still happens if I
set 'limit' to 10. This is on GNU/Linux x86, m4
Hi Eric,
* Eric Blake wrote on Fri, Aug 15, 2008 at 06:22:11AM CEST:
According to Ralf Wildenhues on 8/14/2008 12:39 PM:
Also, should it be named slightly differently since it behaves more
like m4_map than m4_foreach?
m4_map_pair maybe?
I went with the name m4_transform_pair, since
it
on OpenMPI which uses AS_IF a lot.
And yes, I have changed my mind about this from what I wrote earlier
(off-list). The factorization is very nice indeed, the slowdown is
apparently in the noise range, and the change looks safer than I feared.
For example, is my new macro m4_foreach_pair worth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 8/14/2008 12:39 PM:
For example, is my new macro m4_foreach_pair worth documenting as a
supported
interface, or should I leave it undocumented?
How about documenting it after 2.63, so we can change it until the
/it // in the patch below to (hopefully) make this
clearer now.
Furthermore, I previously overlooked the missing but necessary M4 quotes
in the following sentence:
| In particular, @samp{AC_REQUIRE([FOO])} ..
An example for n-ary AS_IF would help, in the manual.
I'm not proud of the one I added
2) Made AS_IF n-ary. Then, I extended the test suite because I tripped
in the why in the world should AS_IF need to be m4_defun'ed? trap
and don't want that to happen again.
1) Add a couple of notes to the docs to this end. I'm not certain
whether they are too confusing to the (ahem
40 matches
Mail list logo
