On Mon, Jun 23, 2025 at 11:36:19PM +0200, Bruno Haible via Patches for autoconf
- the GNU build system wrote:
> With GNU sed:
>
> $ echo foo | sed -e 's/f.*/line1\nline2/'
> line1
> line2
>
> Even in strict POSIX mode:
>
> $ echo foo | POSIXLY_CORRECT=1 sed --posix -e 's/f.*/line1\nline2/'
> li
On Thu, May 15, 2025 at 12:52:17PM +0100, Sam James wrote:
> Sam James writes:
> > GCC requires `ar` and `ranlib` to have plugin support when using LTO. While
> > the situation has improved as many distributions install the GCC plugin
> > to a location that GNU Binutils can automatically find, thi
Hi,
> This patch adds support for the Algol 68 programming language to
> Autoconf. It is based on the Algol 68 GCC front-end
[..]
> This WIP seems to work well for me, but almost certainly I am doing
> something wrong, so comments are welcome.
As I know nothing about Algol 68 or its implementati
This implements support for NO_COLOR in test suites using AT_COLOR_TESTS
to enable colour by default. NO_COLOR is an informal standard[1] way
for users to express their preference to not use colours by default.
If NO_COLOR is set in the environment to anything other than the empty
string, the def
On 2024-12-06 10:44, Zack Weinberg wrote:
> I'm not sure I understand this. Could you please confirm whether the
> intended semantics are that the command-line --color option overrides
> NO_COLOR if both are used? And whether that is what your change
> actually does?
Yes and yes.
The intention
This implements support for NO_COLOR in test suites using AT_COLOR_TESTS
to enable colour by default. NO_COLOR is an informal standard[1] way
for users to express their preference to not use colours by default.
If NO_COLOR is set in the environment to anything other than the empty
string, the def
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.
>&g
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 pres
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_TYPE_GETGROUPS.
No, I don'
On 2023-10-08, Niels Möller wrote:
> I would have expected that every input that is valid c89 also is valid
> c99, so that support for c99 strictly implies support for c89. But there
> may be some corner case I'm not aware of.
It is not true in general that a valid C89 program is also valid
C99,
On 2022-11-15, Zack Weinberg wrote:
> On Tue, Nov 15, 2022, at 12:49 PM, Nick Bowler wrote:
>> On 2022-11-13, Zack Weinberg wrote:
>>> I have not pushed this, and have only tested it lightly on a current
>>> Linux.
>>> It needs testing on weird old systems, pa
[dropping non-autoconf lists from Cc]
On 2022-11-13, Zack Weinberg wrote:
> I have not pushed this, and have only tested it lightly on a current Linux.
> It needs testing on weird old systems, particularly old AIX, HP-UX, MinGW.
I'd be happy to give it a go on my weird old systems ...
>
> I don
Using : with redirections in a shell function is one of the nonportable
constructs discussed in the Autoconf manual; §11.4 "File Descriptors":
Solaris 10 sh will try to optimize away a : command (even if it is
redirected) ... in a shell function after the first call:
[...]
$ f () { : >$1;
On 2020-03-13, Zack Weinberg wrote:
> This is only a theoretical bug because, as the comments say, “all the
> known shells bail out after a failed exec.” However, a shell that
> doesn’t bail out will instead give the user a flood of nonsensical
> error messages (starting with “as_fn_exit: not fou
The manual says that given e.g., AT_ARG_OPTION_ARG([my-option],
[ --my-option=ARG]), the user can pass either --my-option=val
or --my-option val to the testsuite with equivalent results.
However, if the option name contains a hyphen, only the first
form actually works because the argument parser
Hello,
On 2017-07-20, Michael Haubenwallner
wrote:
> * lib/autoconf/general.m4 (AC_CONFIG_LIBOBJ_DIR): Have config.status
> create $top_builddir/LIBOBJ_DIR by INIT-CMDS, to support out of source
> builds even when nothing else does create $top_builddir/LIBOBJ_DIR.
> Based on discussion in https:/
Hi Eric,
On 2016-09-14, Eric Blake wrote:
[...]
> * lib/autoconf/headers.m4 (AC_HEADER_MAJOR): Check for sysmacros.h
> first, rather than after determining if sys/types.h pollutes the
> namespace.
> * doc/autoconf.texi (Particular Headers) : Expand
> details on usage, and on workarounds for non-u
The current implementation of m4_set_foreach leaves its macro variable
defined to whatever the final element of the set was. This differs
from m4_foreach, which pushes & pops the definition in its expansion.
Since this macro is often used with really short macro names (the
manual has an example w
be marked for
export immediately".
Nevertheless, we can export these values in bash just fine, and they
will be correctly written to the environment:
% cat >test.sh <<'EOF'
foo='() {'
echo "$foo"
export foo
dash -c 'echo "$foo"'
EOF
% bash test.sh
() {
() {
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
ially since AC_PROG_CC is supposed to select the most recent
available mode AND to prefer extended modes over strict conformance
ones.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Currently, if a command registered with AC_CONFIG_COMMANDS_PRE itself
calls AC_CONFIG_COMMANDS_PRE, such commands will never be executed.
This occurs because each invocation of AC_CONFIG_COMMANDS_PRE appends
the argument to one big macro (AC_OUTPUT_COMMANDS_PRE) which is then
expanded once near the
;
> This is *not* a regression, since this issue was already in the
> existing code; but it would be nice to have it fixed in a follow-up
> patch.
FYI, the Autoconf manual[1] explicitly says that such usage is not
allowed:
Macro: AS_ECHO (word)
...
word must be a single she
If the current language is not C, the AC_PROG_CC_C_O macro will never-
theless directly invoke the C compiler, but the file extensions used by
the tests will be appropriate for the current language setting rather
than for the C compiler.
In this case, the test may produce a false negative result i
On 2012-11-13 15:41 -0700, Eric Blake wrote:
> On 11/13/2012 02:35 PM, Nick Bowler wrote:
> > (0) Packages have a simple AC_CONFIG_MACRO_DIR([foo]) and a simple
> > ACLOCAL_AMFLAGS = -I foo and don't do anything weird.
[snipping all commentary on the list of cases]
> &
On 2012-11-13 14:59 -0700, Eric Blake wrote:
> On 11/13/2012 02:37 PM, Nick Bowler wrote:
> > On 2012-11-13 22:37 +0200, Adrian Bunk wrote:
> >> On Tue, Nov 13, 2012 at 02:44:08PM -0500, Nick Bowler wrote:
> >>> On 2012-11-13 20:51 +0200, Adrian Bunk wrote:
>
On 2012-11-13 22:37 +0200, Adrian Bunk wrote:
> On Tue, Nov 13, 2012 at 02:44:08PM -0500, Nick Bowler wrote:
> > On 2012-11-13 20:51 +0200, Adrian Bunk wrote:
> > > libtool will access the same information through a new way that has been
> > > implemented by this patc
ut, this solution trivially maintains support
for (3) and (4) anyway at no additional charge.
[...]
> 4. Upgrade everything, but don't rewrite configure.ac
> Things continue to work as they have
I don't believe this is the case. See above.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On 2012-11-13 20:51 +0200, Adrian Bunk wrote:
> On Tue, Nov 13, 2012 at 09:30:45AM -0500, Nick Bowler wrote:
> > On 2012-11-13 01:12 +0200, Adrian Bunk wrote:
> > > In the future libtool will use the result of tracing
> > > AC_CONFIG_MACRO_DIR_TRACE instead of grep&#x
On 2012-11-12 16:09 -0700, Eric Blake wrote:
> On 11/12/2012 03:41 PM, Nick Bowler wrote:
> > Sorry, I don't understand. You seem to be claiming that the addition of
> > AC_CONFIG_MACRO_DIRS (an entirely new macro, with documented behaviour)
> > to Autoconf will s
On 2012-11-13 01:12 +0200, Adrian Bunk wrote:
> On Mon, Nov 12, 2012 at 05:41:29PM -0500, Nick Bowler wrote:
> > On 2012-11-12 15:19 -0700, Eric Blake wrote:
> >...
> > > But since we can't make it continue to work with the new
> > > semantics of AC_CONF
On 2012-11-12 15:19 -0700, Eric Blake wrote:
> On 11/12/2012 03:13 PM, Nick Bowler wrote:
> >> If libtool will get the information in a different way, then that new
> >> way must return the same information - and that implies that autoconf
> >> now has to do some
On 2012-11-13 00:01 +0200, Adrian Bunk wrote:
> On Mon, Nov 12, 2012 at 03:40:50PM -0500, Nick Bowler wrote:
> >...
> > But I still maintain that it is much easier to not make any changes
> > whatsoever to AC_CONFIG_MACRO_DIR: i.e., do nothing.
> >...
>
> We m
On 2012-11-12 12:42 -0700, Eric Blake wrote:
> On 11/12/2012 12:10 PM, Nick Bowler wrote:
> > On 2012-11-12 11:24 -0700, Eric Blake wrote:
[...]
> >> No, existing use of libtool was intended to honor only the first
> >> AC_CONFIG_MACRO_DIR, but due to a bug, actually hon
On 2012-11-12 11:24 -0700, Eric Blake wrote:
> On 11/12/2012 08:42 AM, Nick Bowler wrote:
> > On 2012-11-09 15:53 -0700, Eric Blake wrote:
> > If the goal is compatibility with existing behaviour of libtool,
> > then we must allow multiple invocations of AC_CONFIG_MACRO_DIR a
n configure.ac. Any package targeting compatibility with as-yet-
unreleased versions of automake (read: such packages are by definition
new developments) and old versions of libtool can simply elide the
macro from their configure.ac, and things will work.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
or historical reference) and marking it deprecated
would be prudent, however.
By the same token, to avoid any regressions, let's not change the
behaviour of AC_CONFIG_MACRO_DIR by suddenly making it do more than
nothing.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
ACK,
> or the expiration of the two-days term (whichever comes first).
I believe patch #3 to hack around the warnings still needs some
consideration. However, I don't think that has to block the other
two, since the warnings in question are not actually caused by the
fir
On 2012-11-02 10:46 +0100, Stefano Lattarini wrote:
> On 10/23/2012 12:59 AM, Nick Bowler wrote:
> > 4) I get a bunch of new warnings from aclocal, of the form:
> >
> > configure.ac:42: warning: DX_EXPORTED_SH is m4_require'd but not
> > m4_defun'd
>
Hi Stefano, sorry for the delay.
On 2012-10-31 11:03 +0100, Stefano Lattarini wrote:
> On 10/23/2012 12:59 AM, Nick Bowler wrote:
> > I am going to try all these patches to automake/autoconf/libtool soon; I
> > will report back with the results!
> >
> Has anybody h
patches that I have).
I am going to try all these patches to automake/autoconf/libtool soon; I
will report back with the results!
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On 2012-10-17 09:25 +0200, Stefano Lattarini wrote:
> On 10/16/2012 10:46 PM, Nick Bowler wrote:
> > I think it's important to have, for testing, a version of aclocal that
> > actually makes use of this feature.
> >
> The reason I wrote this patch is because I want to
ng that we can kill off ACLOCAL_AMFLAGS entirely (this means
patching at least libtool as well as automake and autoconf). While it's
not my call, a testable implementation should be a prerequisite for
merging another macro like this into Autoconf.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
(as it requires duplicating information for no
benefit). Looking at the history, this has been the case for almost
10 years now.
For these reasons, I removed it from all of my packages a while ago
(so I get a gratuitous warning from libtoolize: oh well). Unless the
new macro fixes all of these problems, I'm afraid it will suffer a
similar fate. But maybe, just maybe, AC_CONFIG_MACRO_DIRS will gain
traction where AC_CONFIG_MACRO_DIR never did...
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On 8/16/12, Eric Blake wrote:
> * doc/autoconf.texi (Setting Output Variables) : Mention
> that variable does not overlap with macros.
> * tests/base.at (AC_SUBST): New test.
>
> Signed-off-by: Eric Blake
> ---
>
> I went ahead and whipped something up.
Looks reasonable to me.
Thanks,
Nick
44 matches
Mail list logo
