Re: time for Autoconf 2.72 (was: On time64 and Large File Support)

On Mon, 6 Feb 2023 at 19:23, Zack Weinberg wrote: > On the subject of Debian, we could probably get an RC into experimental > and ask for archive rebuilds and say that we were hoping to get 2.72 > approved for a bookworm stable update. > > zw > Even with the stage of the Debian freeze (at the

Re: New libtool maintainer: request for feedback

Sorry if this is actually covered by more-to-detail suggestions, but I don't know the internal details of autotools well enough to tell if it is. As a maintainer of a autotools using project, I've been waiting for a release that resolves issues with removal of ACLOCAL_AMFLAGS. With newer

Re: autoupdate: "ERROR: end of file in string"

On Fri, 8 Jan 2021 at 14:28, Marko Lindqvist wrote: > > On Tue, 5 Jan 2021 at 01:56, Marko Lindqvist wrote: > > > > Running autoupdate for any active freeciv branch (git clone > > https://github.com/freeciv/freeciv.git) results in an error like: > > > >

Re: autoupdate: "ERROR: end of file in string"

On Tue, 5 Jan 2021 at 01:56, Marko Lindqvist wrote: > > Running autoupdate for any active freeciv branch (git clone > https://github.com/freeciv/freeciv.git) results in an error like: > > /usr/bin/m4:/tmp/au5cPMMa/ac.m4:1100: ERROR: end of file in string > autoupdate: error:

autoupdate: "ERROR: end of file in string"

Running autoupdate for any active freeciv branch (git clone https://github.com/freeciv/freeciv.git) results in an error like: /usr/bin/m4:/tmp/au5cPMMa/ac.m4:1100: ERROR: end of file in string autoupdate: error: /usr/bin/m4 failed with exit status: 1 I'm on Debian Testing (Bullseye). I've tested

Re: Autoconf version number after 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

Re: Making Autoconf 2.70 happen in the near future

I maintain http://www.cazfi.net/crosser/ for cross-compiling bunch of software on linux (mostly debian and ubuntu) targeted to Windows (win64 & win32). I'll make a test build using new autoconf. Not yet sure if I can make it soon already with autoconf head, or will I wait that you have a beta

Re: Skip all version checks with autoconf?

Indeed. When considering addition of a new macro call to configure.ac it often requires a lot of digging (usually from NEWS) to find out if using that macro is safe with current minimum autoconf version requirement. It would be really good if the documentation about macros would say what version

Re: Conflict between standard headers and winsock(2).h

On 22 January 2016 at 13:33, Marko Lindqvist <cazf...@gmail.com> wrote: > When building a project on MSYS2 environment, my configure fails to > find out that the winsock2.h is available there. > Simple AC_CHECK_HEADER() for winsock2.h fails, and so would many &g

Re: Release Autoconf 2.70

On 21 July 2016 at 00:06, Eric Blake wrote: > On 07/20/2016 11:21 AM, Craig Andrews wrote: >> >> what's >> blocking a release? > > Lack of free time from someone with commit rights. How much time it takes to make a release? For the outsider there's not many obviously needed

Automatic autoheader invocations for AC_DEFINE changes in m4-files

We are in the middle of transition from one config header to model of two config headers. The goal is that the new one will contain only such macros that it can be safely #included by another project (assuming another autotools using project, but it shouldn't really matter) Template for the full

Conflict between standard headers and winsock(2).h

When building a project on MSYS2 environment, my configure fails to find out that the winsock2.h is available there. Simple AC_CHECK_HEADER() for winsock2.h fails, and so would many standard macros if it was to be included. The reason for that failure is that while the standard headers (unistd.h

Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used

On 8 September 2014 17:29, Eric Blake ebl...@redhat.com wrote: On 09/08/2014 02:44 AM, Thomas Jahns wrote: On 09/08/14 06:24, Paul Smith wrote: In particular, this: configure:3666: checking whether we are using the GNU C compiler configure:3685: clang -c -mmacosx-version-min=10.6

Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used

On 8 September 2014 22:34, Bastien Chevreux b...@chevreux.org wrote: Down Under there are mammals who got pretty good at imitating duck features lately. That's exactly the reason for autoconf-way: checking for duck ... no Configure failed! Needs to be able to swim, and you've got shark.

Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used

On 8 September 2014 23:51, Bastien Chevreux b...@chevreux.org wrote: On 08 Sep 2014, at 22:30 , Marko Lindqvist cazf...@gmail.com wrote: On 8 September 2014 22:34, Bastien Chevreux b...@chevreux.org wrote: Down Under there are mammals who got pretty good at imitating duck features lately

Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used

On 9 September 2014 00:25, Bastien Chevreux b...@chevreux.org wrote: On 08 Sep 2014, at 23:07 , Marko Lindqvist cazf...@gmail.com wrote: I'm ginving theoretical autoconf-way answer. I admit that in some individual cases the Right Thing(tm) might be too much work in practice, and the check

Blogging about deprecated macros

FYI Recent automake-1.13 release has been keeping me busy as I try to fix the majority (it feels) of FOSS projects upon which it fails, due to AM_CONFIG_HEADER having been removed. So in the hope that projects would be better prepared for future autotool releases, a quick note about autoupdate:

Re: Blogging about deprecated macros

On 7 January 2013 05:10, Jeffrey Walton noloa...@gmail.com wrote: On Sun, Jan 6, 2013 at 10:04 PM, Marko Lindqvist cazf...@gmail.com wrote: FYI Recent automake-1.13 release has been keeping me busy as I try to fix the majority (it feels) of FOSS projects upon which it fails, due

Re: RE : RE : rm -f core cause some troubles

On 16 December 2012 02:18, Paul Eggert egg...@cs.ucla.edu wrote: On 12/15/2012 03:08 PM, Jeffrey Walton wrote: Is the program designed to remove old core files as part of the autoconf process? No, new cores. 'configure' regularly generates programs that dump core, as part of its ordinary

Re: RE : RE : rm -f core cause some troubles

On 9 December 2012 01:45, Paul Eggert egg...@cs.ucla.edu wrote: On 12/08/2012 12:30 PM, PICCA Frédéric-Emmanuel wrote: the right fix is to avoid removing core if this is a directory. Autoconf-generated 'configure' files already do that. That's not the issue. The only issue that has been

Re: Future autoconf package compression

On 8 December 2012 23:01, Jim Meyering j...@meyering.net wrote: Marko Lindqvist wrote: On 2 March 2012 06:45, Eric Blake ebl...@redhat.com wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release

Future autoconf package compression

On 2 March 2012 06:45, Eric Blake ebl...@redhat.com wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release, please speak up now. I just encountered new argument for providing .gz of autoconf also in

Re: Future autoconf package compression

On 24 November 2012 10:58, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 11/24/2012 09:16 AM, Marko Lindqvist wrote: On 2 March 2012 06:45, Eric Blake ebl...@redhat.com wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you

Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror

FWIW my opinion as maintainer of several autoconf-using packages is that it really should be my decision if -Werror given by user is passed to configure tests. However, default could be either way - l just need power to override that. I have at least one test that should fail if -Werror is going

Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror

On 20 September 2012 01:12, Marko Lindqvist cazf...@gmail.com wrote: FWIW my opinion as maintainer of several autoconf-using packages is that it really should be my decision if -Werror given by user is passed to configure tests. However, default could be either way - l just need power

Re: Why conditionally include config.h?

On 14 September 2012 02:43, Eric Blake ebl...@redhat.com wrote: On 09/13/2012 05:22 PM, Kip Warner wrote: Hey list, Why do many autoconfiscated projects bracket inclusion of the generated config.h with #if HAVE_CONFIG_H / #endif. Bad copy-and-paste habits. I've seen some packages where

Re: Search for an header file in different paths

On 18 October 2011 18:14, Alessandro Candini cand...@meeo.it wrote: I see. But gdal have a nice executable called gdal-config, similar to pkg-config: user@host ~ $ gdal-config --cflags -I/usr/include/gdal user@host ~ $ gdal-config --libs -L/usr/lib -lgdal1.7.0 Is there a way to use it

Re: Do not use deprecation flags in releases

2011/6/20 Eric Blake ebl...@redhat.com: On 06/19/2011 04:55 PM, Javier Jardón wrote: Hello, I'm looking for the best solution to deal with the deprecation flags for Glib/GTK+. Most project use them incodiotionally, so releases will break if a in Glib/GTK+ deprecation is introduced. I

Version number constructed with m4_esyscmd not a literal?

Freeciv ( http://www.freeciv.org ) configure.ac has AC_INIT like this: AC_INIT([freeciv], [m4_esyscmd([./fc_version | tr -d '\n'])]) This results in warnings from aclocal, autoheader, autoconf and automake: configure.ac:5: warning: AC_INIT: not a literal: m4_esyscmd([./fc_version | tr -d '\n'])

Re: [Patch] Fix some main() return types

2008/6/17 Eric Blake: Marko Lindqvist cazfi74 at gmail.com writes: A couple of c.m4 macros declare function with return type char, and then return same return value from main(). Attached patch translates character from function into int 0 or 1 to be returned from main(). Which compiler