On Tue, Jan 21, 2025, at 4:53 PM, Dima Pasechnik wrote:
> pytest, a popular Python testing tool/framework, uses files named
> conftest.py for its configuration. OTOH many autoconf macros run
> "rm -f conftest*", clobbering conftest.py in the directory where
> ./configure lives. In our case at least
On Wed, Dec 20, 2023, at 7:41 PM, Alan Coopersmith wrote:
> On 12/20/23 08:16, Zack Weinberg wrote:
>> autoconf-2.72e is now available. This is a *release candidate*
>> for autoconf 2.72 final. Please test it as thoroughly as possible.
>> Testing in Windows- and Darwin-based environments would be
On 12/20/23 08:16, Zack Weinberg wrote:
autoconf-2.72e is now available. This is a *release candidate*
for autoconf 2.72 final. Please test it as thoroughly as possible.
Testing in Windows- and Darwin-based environments would be
particularly helpful. Testing your own project’s configure.ac wit
On Mon, Dec 4, 2023, at 6:28 AM, Richard Purdie wrote:
> On Thu, 2023-11-30 at 16:51 -0500, Zack Weinberg wrote:
>> We are pleased to announce beta release 2.72d of Autoconf. (Versions
>> 2.72a, 2.72b, and 2.72c were development snapshots, not official alpha
>> or beta releases.)
> FWIW we tested
On Thu, 2023-11-30 at 16:51 -0500, Zack Weinberg wrote:
> We are pleased to announce beta release 2.72d of Autoconf. (Versions
> 2.72a, 2.72b, and 2.72c were development snapshots, not official alpha
> or beta releases.)
>
> 2.72 will be a minor bug-fix release. The most significant changes
> ar
Hi Paul,
Was this patch ok?
Is submitting the patch by the mailing list appropriate, or
should I instead submit a bug (enhancement request) via savannah?
thanks,
Luke.
On 23-06-04 01:43, Luke Mewburn wrote:
| On 23-05-26 19:25, Paul Eggert wrote:
| | On 2023-05-25 03:25, Luke Mewburn wrot
On 23-05-26 19:25, Paul Eggert wrote:
| On 2023-05-25 03:25, Luke Mewburn wrote:
| > I think that the autoconf and m4 manuals could have improved
| > cross-references to the regular expression syntax actually supported
| > in autoconf via GNU m4:
|
| Perhaps specific patches?
|
|
On 2023-05-25 03:25, Luke Mewburn wrote:
I think that the autoconf and m4 manuals could have improved
cross-references to the regular expression syntax actually supported
in autoconf via GNU m4:
Perhaps specific patches?
Cross-manual links are a bit of a pain to maintain, but if it's
importan
On 2023-05-24 12:14, Luke Mewburn wrote:
11: autoconf: forbidden tokens, basic FAILED (tools.at:485)
41: autom4te preselections FAILED (tools.at:1545)
Are these known issues on RHEL 8 / CentOS / Fedora style systems?
Is it worth sending more details to
On Mon, Apr 3, 2023 at 9:39 PM Zack Weinberg wrote:
>
> On Mon, Apr 3, 2023, at 12:25 PM, Paul Eggert wrote:
> > On 2023-04-03 01:00, Frederic Berat wrote:
> >> It would have been nice to keep these macro around for backward
> >> compatibility. Assuming they are only used by gnulib, they wouldn't
On Mon, Apr 3, 2023, at 12:25 PM, Paul Eggert wrote:
> On 2023-04-03 01:00, Frederic Berat wrote:
>> It would have been nice to keep these macro around for backward
>> compatibility. Assuming they are only used by gnulib, they wouldn't
>> need to be kept for too long.
>
> Fair enough. I installed t
On 2023-04-03 01:00, Frederic Berat wrote:
It would have been nice to keep these macro around for backward
compatibility. Assuming they are only used by gnulib, they wouldn't
need to be kept for too long.
Fair enough. I installed the attached into Autoconf on savannah, so that
one should be ab
Hi Peter,
Peter Hull writes:
> Hi,
> I've got a problem running scan-build on some C++ 17 code and I'm not
> sure if the cause is me, scan-build or autoconf. I'd welcome any
> advice.
>
> I've made a small test case:(still long, sorry)
>
> $ cat configure.ac
> #
On 2022-10-28 08:49, Paul Smith wrote:
I don't know what this AS_TMPDIR() macro does; I can't find it in a
quick search.
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Initialization-Macros.html#index-AS_005fTMPDIR
Looks like your diagnosis is correct; thank
On Fri, 2022-10-28 at 09:15 +0900, suzuki toshiya wrote:
> AC_CONFIG_COMMANDS([dof_free_bit.h],
> [AS_TMPDIR([alberta])
> TMPDIR=${tmp}
>
> rm -rf ${TMPDIR}],
> [BITS=$(( ${ac_cv_sizeof_long} * 8 ))])
Oh yeah, that's it.
If you're going to remove TMPDIR you better also clear it!!
unset TMPDIR
The error caused by "packageheaders" command defined in your configure.ac
(included in https://www.alberta-fem.de/Downloads/alberta-3.0.0.tar.gz ) ?
#
# Should come last to make sure we can already use the Makefiles.
#
AC_CONFIG_COMMANDS([packageheaders],
#AC_CONFIG_COMMANDS_POST(
[${RM} -rf incl
On 2022/10/17 22:26, Paul Smith wrote:
On Mon, 2022-10-17 at 14:11 +0900, suzuki toshiya wrote:
On my macOS 21 (Monterey), /usr/bin/make is GNU make 3.81
I don't follow MacOS so I can't say what the differences are between
different versions. However, be aware that this is NOT standard GNU
ma
On Mon, 2022-10-17 at 14:11 +0900, suzuki toshiya wrote:
> On my macOS 21 (Monterey), /usr/bin/make is GNU make 3.81
I don't follow MacOS so I can't say what the differences are between
different versions. However, be aware that this is NOT standard GNU
make 3.81 as provided by GNU. This instanc
On my macOS 21 (Monterey), /usr/bin/make is GNU make 3.81, and no gmake is
provided as a part of Xcode command line utility, I think. For newer GNU make,
like 4.x, maybe the users have to consider to use homebrew or something like
that, although I don't know manual installation of newer GNU mak
David A. Wheeler writes:
>> On Jul 6, 2021, at 9:39 AM, Anthony Scemama
>> wrote:
>>
>> Dear autoconf community,
>> I am organizing an online "build system hackathon" for academic scientists on
>> behalf of the TREX european center of excellence in high performance
>> computing
>> (https://t
> On Jul 6, 2021, at 9:39 AM, Anthony Scemama
> wrote:
>
> Dear autoconf community,
> I am organizing an online "build system hackathon" for academic scientists on
> behalf of the TREX european center of excellence in high performance computing
> (https://trex-coe.eu) in November. We want our
On 1/28/21 4:49 PM, Zack Weinberg wrote:
> We are pleased to announce stable release 2.71 of Autoconf.
FYI, at the time this release was made, we neglected the fact that
https://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.* still pointed to
the 2.69 release from 2012. I just fixed that today, us
Zack Weinberg wrote:
> ...
> grumpy aside in OpenBSD's "fcntl(2)" manpage:
>
> | This interface follows the completely stupid semantics of System V
> | and IEEE Std 1003.1-1988 ("POSIX.1") that require ...
>
> As I recall, at the time, *neither* flock nor fcntl locks
> were honored *at all* over N
On Thu, Jan 28, 2021 at 4:21 PM Zack Weinberg wrote:
> On Tue, Jan 5, 2021 at 9:31 AM Zack Weinberg wrote:
> > After thinking about it a bit more, this technical argument against
> > three-part versions is quite compelling ... but I still find the
> > marketing argument *for* three-part versions
On Tue, Jan 5, 2021 at 9:31 AM Zack Weinberg wrote:
> After thinking about it a bit more, this technical argument against
> three-part versions is quite compelling ... but I still find the
> marketing argument *for* three-part versions to be quite compelling.
> I would like to hear some more peopl
On 1/28/21 10:34 AM, Zack Weinberg wrote:
we could instead use the
battle-tested technique used by Emacs: symlink sentinels. (See
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/filelock.c .)
Although that Emacs code is battle-tested, one of the things it does is
fall back on regular fi
On Thu, 28 Jan 2021, Nick Bowler wrote:
If I understand correctly the issue at hand is multiple concurrent
rebuild rules, from a single parallel make implementation, are each
invoking autom4te concurrently and since file locking didn't work,
they clobber each other and things go wrong.
That is
On Thu, 28 Jan 2021, Zack Weinberg wrote:
Do you use different versions of autoconf and/or automake on the
different clients?
No. That would not make sense. If a client is not suitably prepared,
then I don't enable maintainer mode.
The lock appears to be taken speculatively since it is t
On 2021-01-28, Zack Weinberg wrote:
> There is a potential way forward here. The *only* place in all of
> Autoconf and Automake where XFile::lock is used, is by autom4te, to
> take an exclusive lock on the entire contents of autom4te.cache.
> For this, open-file locks are overkill; we could inste
On Thu, Jan 28, 2021 at 2:16 PM Bob Friesenhahn
wrote:
> On Thu, 28 Jan 2021, Zack Weinberg wrote:
> >
> > The main reason I can think of, not to do this, is that it would make
> > the locking strategy incompatible with that used by older autom4te;
> > this could come up, for instance, if you’ve g
On Thu, 28 Jan 2021, Zack Weinberg wrote:
The main reason I can think of, not to do this, is that it would make
the locking strategy incompatible with that used by older autom4te;
this could come up, for instance, if you’ve got your source directory
on NFS and you’re building on two different cl
On Mon, Jan 25, 2021 at 11:18 AM Bob Friesenhahn
wrote:
> On Mon, 25 Jan 2021, Zack Weinberg wrote:
> > Automake "just" calls Perl's 'flock' built-in (see 'sub lock' in
> > Automake/XFile.pm) (this code is copied into Autoconf under the
> > Autom4te:: namespace). It would be relatively straightfo
On Mon, 25 Jan 2021, Zack Weinberg wrote:
Automake "just" calls Perl's 'flock' built-in (see 'sub lock' in
Automake/XFile.pm) (this code is copied into Autoconf under the
Autom4te:: namespace). It would be relatively straightforward to
teach it to try 'fcntl(F_SETLKW, ...)' if that fails. Do y
On Mon, Jan 25, 2021 at 9:52 AM Bob Friesenhahn
wrote:
> At the moment it is a big deal for me because the locking prototol
> that Autoconf/Automake is using does not work with NFS mounts for
> Illumos-derived systems when the client is also an Illumos-derived
> system, because Illumos failed to s
On Sun, 24 Jan 2021, Paul Eggert wrote:
On 1/23/21 4:06 PM, Bob Friesenhahn wrote:
A tiny fork/exec is not a big deal.
It is indeed not a big deal. That being said, one can optimize away GNU
make's fork and exec by using "@:" instead of "@true".
At the moment it is a big deal for me becau
On Sun, 24 Jan 2021, Zack Weinberg wrote:
On Sun, Jan 24, 2021 at 7:27 PM Bob Friesenhahn
wrote:
AC_SUBST([CONFIGURE_DEPENDENCIES],["$CONFIGURE_DEPENDENCIES \$(top_srcdir)/ChangeLog
\$(top_srcdir)/version.sh"])
Why did you write it like this instead of
CONFIGURE_DEPENDENCIES = $(top_srcdi
On 2021-01-24, Peter Johansson wrote:
> I've managed to reproduce the behavior Bob describes in the attached
> script. If we touch the timestamp of configure.ac, running autoconf will
> update the timestamp of configure. But if the autoconf is triggered by
> something else for example if ChangeLog
On 25/1/21 11:33 am, Zack Weinberg wrote:
On Sun, Jan 24, 2021 at 7:27 PM Bob Friesenhahn
wrote:
AC_SUBST([CONFIGURE_DEPENDENCIES],["$CONFIGURE_DEPENDENCIES \$(top_srcdir)/ChangeLog
\$(top_srcdir)/version.sh"])
Why did you write it like this instead of
CONFIGURE_DEPENDENCIES = $(top_srcdir)
On 1/23/21 4:06 PM, Bob Friesenhahn wrote:
A tiny fork/exec is not a big deal.
It is indeed not a big deal. That being said, one can optimize away GNU
make's fork and exec by using "@:" instead of "@true".
On Sun, Jan 24, 2021 at 7:27 PM Bob Friesenhahn
wrote:
>
> AC_SUBST([CONFIGURE_DEPENDENCIES],["$CONFIGURE_DEPENDENCIES
> \$(top_srcdir)/ChangeLog \$(top_srcdir)/version.sh"])
Why did you write it like this instead of
CONFIGURE_DEPENDENCIES = $(top_srcdir)/ChangeLog $(top_srcdir)/version.sh
dir
On Mon, 25 Jan 2021, Peter Johansson wrote:
Hi Bob,
On 24/1/21 10:06 am, Bob Friesenhahn wrote:
I did try this type of solution. As I recall, it did not help because the
terminal target is Automake's regeneration rules, which are apparently
optimized to not modify the target files (e.g. conf
Hi Bob,
On 24/1/21 10:06 am, Bob Friesenhahn wrote:
I did try this type of solution. As I recall, it did not help because
the terminal target is Automake's regeneration rules, which are
apparently optimized to not modify the target files (e.g. configure)
if there was no change.
This seems l
On Sat, 23 Jan 2021, Zack Weinberg wrote:
I’m sorry this has been such a frustrating experience for you, and I’m
also sorry I didn’t react to this thread earlier. I thought you had
already found an approach that _did_ work for you.
I thought so to. While developing GraphicsMagick, I use a di
On Sat, Jan 23, 2021 at 11:38 AM Bob Friesenhahn
wrote:
>
> I am about to give up on using the new style AC_INIT in the form of
>
> AC_INIT(m4_esyscmd([./version.sh packagename]),
> m4_esyscmd([./version.sh packageversion]),
> m4_esyscmd([./version.sh packagebugreport]),
>
I am about to give up on using the new style AC_INIT in the form of
AC_INIT(m4_esyscmd([./version.sh packagename]),
m4_esyscmd([./version.sh packageversion]),
m4_esyscmd([./version.sh packagebugreport]),
m4_esyscmd([./version.sh packagetarname]),
m4_esyscmd([./vers
On Thu, 14 Jan 2021, Peter Johansson wrote:
I suspect it would be possible to solve by splitting the timestamps into two
different files. One is the VERSION file determining when autoconf needs to
be run and a timestamp file determines when the version.sh script needs be
run. Something like:
On 13/1/21 12:37 pm, Bob Friesenhahn wrote:
This seems like a Catch-22 situation. If the VERSION file timestamp
does not get updated, it will produce this noise, and if does get
updated, then there is a whole reconf-config-build cycle.
Is there any solution for that?
I suspect it would b
On Tue, 12 Jan 2021, Peter Johansson wrote:
The problem is that there is no dependency in the Makefile telling that
autoconf need to be rerun when the version has changed. Automake has the
variable 'CONFIGURE_DEPENDENCIES' for this purpose, so adding
CONFIGURE_DEPENDENCIES = ChangeLog
would s
On Wed, 13 Jan 2021, Peter Johansson wrote:
I don't see any way without a specific file holding the timestamp on when
the version was last updated.
This is very helpful advice (and adds to valuable advice offered in private
emails by others). I don't really like hidden files but I do have a
Hi Bob,
On 13/1/21 12:35 am, Bob Friesenhahn wrote:
On Tue, 12 Jan 2021, Peter Johansson wrote:
The problem is that there is no dependency in the Makefile telling
that autoconf need to be rerun when the version has changed. Automake
has the variable 'CONFIGURE_DEPENDENCIES' for this purpose,
On Tue, 12 Jan 2021, Peter Johansson wrote:
The problem is that there is no dependency in the Makefile telling that
autoconf need to be rerun when the version has changed. Automake has the
variable 'CONFIGURE_DEPENDENCIES' for this purpose, so adding
CONFIGURE_DEPENDENCIES = ChangeLog
would
Hi Bob,
On 12/1/21 10:35 am, Bob Friesenhahn wrote:
I recently updated GraphicsMagick to use the 5 argument form of
AC_INIT and the one argument form of AM_INIT_AUTOMAKE. I also used
m4_esyscmd to get version info from an external script. The
invokation looks like this:
AC_INIT(m4_esyscmd(
On Wed, Jan 6, 2021 at 1:56 PM Eli Schwartz wrote:
> On 1/5/21 9:31 AM, Zack Weinberg wrote:
> > On Mon, Jan 4, 2021 at 5:52 PM Paul Eggert wrote:
> >> On 1/4/21 1:45 PM, Zack Weinberg wrote:
> >>
> >>> it sounds like your concern is not so much with a three-part
> >>> _numbering scheme_, but wi
On 1/5/21 9:31 AM, Zack Weinberg wrote:
On Mon, Jan 4, 2021 at 5:52 PM Paul Eggert wrote:
On 1/4/21 1:45 PM, Zack Weinberg wrote:
it sounds like your concern is not so much with a three-part
_numbering scheme_, but with the possiblity that we might put out
2.70.n _after_ 2.71. What if we say
I would like to hear some more people's opinions; cc:ing Eric and
Karl.
Well, since you asked, it's not a big issue to me, but I am not a fan of
3-part versions. In addition to Paul's points:
1) What I've noticed is that they set up various expectations about
releases which, in practice,
On Mon, Jan 4, 2021 at 5:52 PM Paul Eggert wrote:
> On 1/4/21 1:45 PM, Zack Weinberg wrote:
>
> > it sounds like your concern is not so much with a three-part
> > _numbering scheme_, but with the possiblity that we might put out
> > 2.70.n _after_ 2.71. What if we say that, at least for the time
On 1/4/21 1:45 PM, Zack Weinberg wrote:
it sounds like your concern is not so much with a three-part
_numbering scheme_, but with the possiblity that we might put out
2.70.n _after_ 2.71. What if we say that, at least for the time being
(until some hypothetical future where the project has a lo
On Thu, Dec 31, 2020 at 3:41 AM Paul Eggert wrote:
>
> On 12/30/20 11:23 AM, Zack Weinberg wrote:
>
> > we need to make a more careful distinction between minor releases
> > that might have compatibility issues, and point releases that were
> > guaranteed only to fix bugs, than we used to. Specif
On Thu, 31 Dec 2020, Paul Eggert wrote:
I'm more of an Autoconf user than I am an Autoconf developer, and from the
user point of view I'd rather keep things simple, and stick with 2.71 when it
comes out, and then to 2.72 when it comes out, etc.
+1 on this.
There is no reason to "ride herd"
On 12/30/20 2:47 PM, David A. Wheeler wrote:
most programs of autoconf’s size have switched to semantic versioning (SemVer),
where 3 numbers are required.
Many programs use SemVer, but many don't. Emacs doesn't. Coreutils
doesn't. Grep doesn't. Mailutils doesn't. GNU parallel doesn't. Ubuntu
On 12/30/20 11:23 AM, Zack Weinberg wrote:
we need to make a more careful distinction between minor releases
that might have compatibility issues, and point releases that were
guaranteed only to fix bugs, than we used to. Specifically, I think
we need to maintain a release branch based on 2.70
On Wed, 30 Dec 2020 at 21:24, Zack Weinberg wrote:
> Leaving that aside for now, I think Autoconf (the project) is in a
> different place now than it was at the time of 2.66,
And IMO the practice in use was not good even back then. There was
several autoconf versions released within couple of mon
> On Dec 30, 2020, at 2:23 PM, Zack Weinberg wrote:
>
> On Wed, Dec 23, 2020 at 7:59 PM Paul Eggert wrote:
>>
>> Given the changes being discussed (which seem good ones), I suggest
>> calling the next Autoconf release 2.71 not 2.70.1, as the latter
>> would use a new-to-Autoconf numbering co
On Wed, Dec 23, 2020 at 7:59 PM Paul Eggert wrote:
>
> Given the changes being discussed (which seem good ones), I suggest
> calling the next Autoconf release 2.71 not 2.70.1, as the latter
> would use a new-to-Autoconf numbering convention that might be more
> trouble than it's worth.
>
> There w
Hi all,
There was little difference (and only a month) between Autoconf 2.66 and
2.67, so there's precedent for putting only a few changes into Autoconf
2.71 and publishing it relatively quickly.
I would even say it is "normal" for a quick 2.71 release.
8 years had passed since latest 2.69 re
On Tue, Dec 08, 2020 at 02:14:30PM -0500, Zack Weinberg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> We are pleased to announce stable release 2.70 of GNU Autoconf.
>
> This release includes eight years of development work since the
> previous release, 2.69. Noteworthy changes
Woohoo!! About time! :)
On Tue, Dec 8, 2020 at 12:14 PM Zack Weinberg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> We are pleased to announce stable release 2.70 of GNU Autoconf.
>
> This release includes eight years of development work since the
> previous release, 2.69. Note
Zack,
Thank you for all the work and time you put into this project. I think I
speak for the community when I say this was a true gift.
John
On Tue, Dec 1, 2020, 9:26 AM wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> It's been four weeks since the release of autoconf 2.69d. I
Hi Zack,
Am Mon, 2 Nov 2020 17:23:29 -0500
schrieb Zack Weinberg :
> It’s been five weeks since the release of autoconf 2.69c. Many bugs
> have been fixed, and I had hoped to be able to put out the final
> release of 2.70 this week, but there are still some important bugs
> that need to be fixed
On 11/2/20 5:23 PM, Zack Weinberg wrote:
It’s been five weeks since the release of autoconf 2.69c. Many bugs
have been fixed, and I had hoped to be able to put out the final
release of 2.70 this week, but there are still some important bugs
that need to be fixed before we can do that.
(Testing
On Wed, Oct 28, 2020 at 12:45 PM Jannick wrote:
>
> On Tue, 27 Oct 2020 13:59:21 +0100, Jannick wrote:
> > If the system makes configure read in a config.site script, then
> >
> > 36: autoupdating AC_OBSOLETEFAILED (tools.at:1342)
> >
> > because the comparison of config.lo
On Tue, 27 Oct 2020 13:59:21 +0100, Jannick wrote:
> If the system makes configure read in a config.site script, then
>
> 36: autoupdating AC_OBSOLETEFAILED (tools.at:1342)
>
> because the comparison of config.log is not prepared to see the additional
> line in config.log
>
On Sun, Oct 18, 2020 at 9:59 AM Michael Orlitzky wrote:
> One of our developers is trying to build all of Gentoo with the new
> autoconf-2.69c and the AC_INIT quoting patch. Build failures will block
> this bug: https://bugs.gentoo.org/732648
Thanks for doing this!
You should apply
https://git.
On Wed, 30 Sep 2020, Zack Weinberg wrote:
In particular, the AC_*_IFELSE macros have been available since
version 2.55, which was released in 2002(!)
Well, this configure script was first implemented in 1996 to replace
something called 'imake'. I am sure that there must be many more
things
On 9/30/20 8:41 AM, Zack Weinberg wrote:
>> Most probably either 'git-version-gen' or some use of 'git describe'
>> can achieve this.
>
> I just built autoconf (the program) from a completely clean checkout
> of git trunk, which is currently two commits after the v2.69c tag, and
> it identified i
On Sun, Sep 27, 2020 at 2:03 PM Bob Friesenhahn
wrote:
>
> Today I am trying autoconf-2.69c with GraphicsMagick's configure.ac
> and am only encountering utter failure.
It sounds like you already got a bunch of help and most of the
problems are resolved. I just want to add a few notes:
- As oth
On Sun, Sep 27, 2020 at 7:10 PM Bruno Haible wrote:
>
> Paul Eggert wrote:
> > > I don't know where you got this magic number 301-14265 from.
> >
> > I got it by checking out the then-current commit of Autoconf from Savannah
> > git,
> > and building from that.
> >
> > Presumably doing the right
On Tue, Sep 29, 2020 at 8:04 PM Russ Allbery wrote:
>
> This is separate from the question of how Autoconf should handle old
> configure scripts and how autoupdate should work, but while you're
> manually making changes to macros anyway, you will probably be happier in
> the long run if you quote
Bob Friesenhahn writes:
> Gavin, thanks very much for your help. Just in case someone reads this
> discussion later, I found that there was a small syntax error in the
> above. The following is what finally worked for me (a small change after
> ac_cv_have_C__func__='no'):
> # Test for C compil
On Sun, 27 Sep 2020, Gavin Smith wrote:
That should be:
if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
[[const char *func=__func__;
return (func != 0 ? 0 : 1);
]])],
[ac_cv_have_C__f
Paul Eggert wrote:
> > I don't know where you got this magic number 301-14265 from.
>
> I got it by checking out the then-current commit of Autoconf from Savannah
> git,
> and building from that.
>
> Presumably doing the right thing here would mean a fix to Autoconf's
> m4_version_prereq macro
On 9/27/20 2:55 PM, Bruno Haible wrote:
I don't know where you got this magic number 301-14265 from.
I got it by checking out the then-current commit of Autoconf from Savannah git,
and building from that.
Presumably doing the right thing here would mean a fix to Autoconf's
m4_version_prereq
[CCing Autoconf list again]
Paul Eggert wrote:
> I am assuming that "m4_version_prereq([2.69.301-14265], ...)" does the right
> thing with Autoconf beta version numbers; if not, that's an Autoconf bug that
> should get fixed
Well, I don't know where you got this magic number 301-14265 from.
> Maybe it is a problem with changequote being used inside an argument to
> a macro. Does it work OK when you remove the changequote lines?
>
> if test "$ac_cv_have_C__func__" != 'yes' ; then
> AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
> [AC_COMPILE_IFELSE([AC_LANG_PR
On Sun, Sep 27, 2020 at 01:56:06PM -0500, Bob Friesenhahn wrote:
> On Sun, 27 Sep 2020, Gavin Smith wrote:
> >
> > It might help if you could post what the AC_TRY_COMPILE statements were
> > changed into. If I understand correctly the definition in
> > autoconf/general.m4
>
> That would certainl
On Sun, 27 Sep 2020, Gavin Smith wrote:
It might help if you could post what the AC_TRY_COMPILE statements were
changed into. If I understand correctly the definition in
autoconf/general.m4
That would certainly help and it is perhaps likely that there is some
syntax weakness in the original.
On Sun, 27 Sep 2020, Paul Eggert wrote:
On 9/27/20 11:23 AM, Bob Friesenhahn wrote:
Is 'autoupdate' supposed to be safe to use?
I would never trust the output of 'autoupdate', no. It's meant to be
suggestions and/or indications of problems, and is not meant to be
authoritative. Perhaps this
> I am also concerned that the first active line after executing 'autoupdate'
> is this:
>
> AC_PREREQ([2.69c])
>
> Presumably this means that version 2.69c is required to re-autoconf the
> configure script. I certainly could not impose this overwhelming burden on
&
On 9/27/20 11:23 AM, Bob Friesenhahn wrote:
Is 'autoupdate' supposed to be safe to use?
I would never trust the output of 'autoupdate', no. It's meant to be suggestions
and/or indications of problems, and is not meant to be authoritative. Perhaps
this should be stated more clearly in the docu
On Sun, 27 Sep 2020, Bob Friesenhahn wrote:
A great many macros (still used to provide backward compatibility) are now
declared as obsolete. I ran 'autoupdate' and see that AC_TRY_COMPILE
statements were changed to use new syntax. The problem is that with the
replacement code it inserted I
-L to change it
autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1
I am also concerned that the first active line after executing
'autoupdate' is this:
AC_PREREQ([2.69c])
Presumably this means that version 2.69c is required to re-autoconf
the configure script. I certainly
I asked:
> Hi Paul,
>
> > (I did reproduce the bug).
>
> Have you reproduced the warning
> "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS"
> with autoconf 2.63 but not 2.64 ?
This is indeed the case. With this simple configure.ac
=
> diff --git a/ChangeLog b/ChangeLog
> index 8c06171aa..c77f19a68 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,8 @@
> +2020-09-27 Gavin Smith
> +
> + threadlib, libcrypt: use AS_HELP_MESSAGE instead of AC_HELP_MESSAGE.
> + * m4/threadlib.m4, m4/libgcrypt.m4: Update macro use.
> -AC_PREREQ([2.60])
> +AC_PREREQ([2.69])
I left this in by mistake from autoupdate; I'd guess it should be left
as 2.60.
On Sat, Sep 26, 2020 at 07:20:40PM -0700, Paul Eggert wrote:
> On 9/26/20 10:47 AM, Zack Weinberg wrote:
>
> > > Would it be right to say that this should be changed in Gnulib,
> > > otherwise any project using that file with Gnulib will have errors
> > > from the new autoconf?
> >
> > Yes, indee
Hi Paul,
> (I did reproduce the bug).
Have you reproduced the warning
"AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS"
with autoconf 2.63 but not 2.64 ?
I'm asking because when I added that comment on 2009-01-25, the newest
released version at that moment was 2.63. So, unless you
On 9/26/20 10:47 AM, Zack Weinberg wrote:
Would it be right to say that this should be changed in Gnulib,
otherwise any project using that file with Gnulib will have errors
from the new autoconf?
Yes, indeed. All of the Gnulib and Autoconf Macro Archive macros need
to be checked for problems
On Sat, Sep 26, 2020 at 8:15 AM Gavin Smith wrote:
> On Fri, Sep 25, 2020 at 9:07 PM Gavin Smith wrote:
> >
> > > * Warnings about obsolete constructs are now on by default.
> > > They can be turned off with '-Wno-obsolete'.
> > >
> >
> > I have tried building the git development version of Tex
On Fri, Sep 25, 2020 at 9:07 PM Gavin Smith wrote:
>
> > * Warnings about obsolete constructs are now on by default.
> > They can be turned off with '-Wno-obsolete'.
> >
>
> I have tried building the git development version of Texinfo with
> the new autoconf, but am deluged with warnings. I get
> * Warnings about obsolete constructs are now on by default.
> They can be turned off with '-Wno-obsolete'.
>
I have tried building the git development version of Texinfo with
the new autoconf, but am deluged with warnings. I get the following
warnings from autoconf:
configure.ac:87: warnin
1 - 100 of 1561 matches
Mail list logo
