Re: Which Perl versions Autoconf needs

On Mar 29, 2023, at 20:29, Jacob Bachmeyer wrote: > > Digest::SHA was installable from CPAN long before it was a core module More to the point, it’s _still_ installable that way, and the current version’s minimum Perl requirement is 5.3.0, from 1996: https://metacpan.org/pod/Digest::SHA

Re: [bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is not available

On Mar 28, 2023, at 01:15, Paul Eggert wrote: > > Solaris 10 has only Perl 5.8.4. As one who has griped to various software projects in the past about breaking compatibility with old versions of Perl, I sympathize, but I thought the Autoconf Way is to build configure scripts on a modern

Re: Parallelization of shell scripts for 'configure' etc.

A Makefile can be viewed as a series of shell scripts interconnected by dependency rules that dictate which elements can be safely skipped, which must be run, and in what order. I believe it's possible to recast Autoconf so that it generates a Makefile that produces the same outputs as a

Re: config.sub/config.guess using nonportable $(...) substitutions

On Tue, Mar 9, 2021 at 2:50 PM Michael Orlitzky wrote: > > the $(...) syntax was standardized no later than 1997 It was first formally standardized as part of the POSIX shell in 1989, which standardized what used to be called ksh88

Re: config.sub/config.guess using nonportable $(...) substitutions

On Mar 9, 2021, at 1:26 PM, Paul Eggert wrote: > >> 1) There is no actual benefit to using $(...) over `...`. > > I disagree with that statement on technical grounds (not merely cosmetic > grounds), as I've run into real problems in using `...` along with " and \, Me too, plus nesting. The

Re: Autotools lint tool

On Oct 2, 2019, at 9:58 PM, Gabriel Lisaca wrote: > > Sorry, I may have made my question unclear. What I meant by a "lint" tool for > autoconf (and the autotools in general) is to check rather trivial things > like syntax and arguments to macros to conform to what the documentation > intends

Re: Autotools lint tool

On Oct 2, 2019, at 7:05 PM, Gabriel Lisaca wrote: > > wondering if there are any lint tools available for checking the > "correctness" of a project's configure.ac file as well as its Makefile.am file I don’t think it’s a practical possibility, since it would amount to “Emulate the build

Re: [bug-gettext] failure in building po/Makefile due to crippled sed

On Mar 7, 2019, at 5:09 PM, Perry Hutchison wrote: > > * Yes, I am aware of Chromebrew; I am using it as a starting point > but trying to bootstrap as much as possible from source rather than > installing from binary packages (long story). Are you also aware of Crouton?

Re: Skip all version checks with autoconf?

On Aug 25, 2018, at 10:23 AM, Basin Ilya wrote: > > I have a VM with RHEL 6.8, because that's what our customers build our > software on. And when I change anything in configure.ac, I test it there. > Of course, such conservative attitude is unnecessary for open source > projects, but

Re: Make and subdir

On Jul 30, 2018, at 2:38 PM, Mauricio Ramirez wrote: > This has worked great on RedHat 5, but when we're moving to Redhat 7, it > fails when building mylibrary. It can't find some includes. If I go into > the mylibrary directory, and do the make, it works just fine. Not > understanding why I

Re: How to write directly to config.h from configure?

On Jul 26, 2018, at 9:36 AM, Jeffrey Walton wrote: > >cat << EOT >> config.h > typedef unsigned char byte; > typedef unsigned short word16; > typedef unsigned int word32; >EOT You’re reinventing C99’s stdint.h here. Unless you still must build on C89 or older compilers,

Re: How to change the shebang in 'configure' to require Bash

On Mar 20, 2018, at 4:07 AM, R. Diez wrote: > > I know that Autoconf developers want to write extremely portable scripts. But > that is a huge barrier for somebody like me. I am a user, not a shell expert. Your argument attempts to have it both ways: Bourne and POSIX

Re: How to change the shebang in 'configure' to require Bash

On Mar 19, 2018, at 7:57 AM, Eric Blake wrote: > > On 03/18/2018 10:39 AM, R. Diez wrote: >> I realise that this decision goes against Autoconf's portability principle. >> But even as a humble user, I am entitled to some freedom of choice. 8-) > > Not any easy way that I

Re: [PATCH] autoheader: check templates of all config headers

On Oct 9, 2015, at 10:48 PM, Paul Eggert wrote: > > The basic idea for this sounds good; thanks. It'd be nice if someone else > who uses Perl more than I could look over the details. Well, I know Perl, but I don’t know the autotools internals, so all I can do is nitpick

Re: autocon and sub-packages

On Sep 4, 2015, at 6:26 AM, Sébastien Hinderer wrote: > > Eric Blake (2015/09/04 06:07 -0600): >> >> https://www.gnu.org/software/gettext/manual/gettext.html#AM_005fGNU_005fGETTEXT >> https://www.gnu.org/software/libtool/manual/libtool.html#Distributing-libltdl > > Thank. I think the bundle

Re: autocon and sub-packages

On Sep 4, 2015, at 12:46 PM, Sébastien Hinderer wrote: > > Warren Young (2015/09/04 12:27 -0600): > >> If you’re using libraries that are also not yet ubiquitous, the >> alternative to providing the sub-packages with the main package is to >> add a hard-fail autoconf t

Re: autocon and sub-packages

On Sep 4, 2015, at 1:45 PM, Warren Young wrote: > > I’m referring to the fact that with embedded tarballs, you can’t call > AC_CONFIG_SUBDIRS() By the way, the how-to of conditional AC_CONFIG_SUBDIRS() is a FAQ. One set of answers is here: http://stackoverflow.com/questions

Re: Why configure failed to search libws2_32.a in MinGW+MSYS ?

On 12/27/2013 01:58, Guo Leaveye wrote: After first `autoconf' failure, my `autoreconf -i' succeed, and the `./configure' reports: Care to post your config.log so someone doesn't have to dummy up a whole project just to test this for you? ___

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

On 5/17/2013 13:05, Henrique de Moraes Holschuh wrote: It would have been really useful if autofoo used whatever is in /usr/share/misc, unless there is a config.sub.override or config.guess.override file You're starting from an assumption that autotools are installed on all systems where you

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

On 5/15/2013 14:27, Mike Frysinger wrote: On Wednesday 15 May 2013 15:25:31 Warren Young wrote: we've got pretty good coverage for anything passably relevant (and then some). So, because Gentoo has N text editors in the repo, the N+1th text editor must port to Gentoo without problems

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

On 5/15/2013 11:20, Mike Frysinger wrote: i understand the point you're making. however, ~10 years of building from source in Gentoo and doing this for every single build has shown that in practice, it's irrelevant. It's irrelevant *for* *Gentoo*. Not all autoconfiscated source trees are

configure rebuild rule not passing on -I to aclocal

My bootstrap script conditionally adds a -I flag to the aclocal command on Mac platforms when it sees that we've installed the Homebrew version of gettext (for AM_ICONV) since for reasons I forget, it works better for us than the the platform one. The logic looks like this: if [ -d

Re: Autoconf distributions and xz dependency

On 3/6/2012 2:31 AM, Olaf Lenz wrote: On 03/06/2012 10:27 AM, Alberto Luaces wrote: Warren Young writes: At least version 1.26 implements -a, which determines the compressor from the file suffix. I think that may be a red herring, because... I think since some years now I don't need

Re: Autoconf distributions and xz dependency

On Thu, 1 Mar 2012, Eric Blake wrote: The Autoconf team is considering releasing only .xz files for 2.69; What problem are y'all trying to solve here? Is gnu.org running out of disk space or bandwidth? I hope you're not just trying to save disk space. I did a little math here and it

Re: Autoconf distributions and xz dependency

On 3/2/2012 5:10 PM, Eric Blake wrote: we are doing users a favor by getting xz installed and commonly available in more places. I went through both the .Z - .gz and .gz - .bz2 transitions. I recall a longer overlap period where major archive sites had everything in both the new and

Re: SMP configuration

On 5/17/2010 10:40 AM, Eric Blake wrote: On 05/17/2010 08:09 AM, Michael Menegakis wrote: On windows, probably because I had heard windows are very slow in creating new processes unlike UNIX, configuration is mindbogglingly slow. I wonder if there's a way to run it SMP ..-ish.. How is SMP

Re: SMP configuration

On 5/17/2010 3:01 PM, Eric Blake wrote: The quagmire project uses make to perform its parallel checks, but it requires that end users have GNU make installed. That may not be an unreasonable prereq these days. The 3rd edition of the O'Reilly make book (2004) dropped coverage of all other

Re: Best practices for autotools

On 5/3/2010 10:11 PM, Gary V. Vaughan wrote: CAVEAT EMPTOR: While it is certainly worth skimming through the autobook to get a feel for how the various programs interact and can be used together, the book will be 10 years old this year, and much has changed in that time that makes plenty of the

Re: autoconf in Perl

Shakthi Kannan wrote: If 'configure' is in Perl... Maybe, I am missing something here. The whole point of autoconf is to help make software portable. Plain ol' Bourne shell is on more systems than Perl, hence software is more portable when configure is a Bourne shell script.

Re: Specifying which shell to use

Dan Smithers wrote: If I edit configure by hand to start #! /bin/bash it works. You shouldn't be writing configure tests that depend on Bash. The whole point of autoconf is that it lets you test for features on a system whose capabilities you do not yet fully understand. One of those

Re: Library version thru autoconf ?

Sébastien Le Roux wrote: I wonder if there is a way (a macro ?) to obtain the version of a library. Maybe, but the Autoconf Way is to test for features, not versions. Take the simple case, only two supported versions of a library, old and new. You write a single autoconf test that tries to

Re: Feature Request: Administrator Install

David Masterson (damaster) wrote: After I've done the usual configure; make; make install; to install the package and then remove the source code, Why remove the sources? After configuration, they have all the information you are asking for. If it's about saving disk space, most of the

ACLOCAL_AMFLAGS without automake

Just a feature request for autoreconf: the ability to get the equivalent of aclocal -I dirname with ACLOCAL_AMFLAGS is fine if you're using automake, but not all projects do. (I'm using Bakefile, for instance, because I also need to generate Visual C++ project files and such.) It'd be great

Re: Please help

Murtaza wrote: I am getting the following error while running make. I am sure someone would have faced this error before. If so please help me. Makefile is there in the folder. autoconf make: autoconf: Command not found Maybe it's because the autoconf command is not found, which would happen

Re: conversion to git

Paul Smith wrote: Savannah does not support SubversionSo, I'm stuck with CVS, Maybe you can switch to Savannah's evil twin, Gna. http://gna.org/ ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: Binary Version for Mac OS X?

herb wrote: Would it break any rules, such as the fact that the Mac OS X Installer program is proprietary software? Even though Installer is proprietary software, the package is not software at all, and installer is just opening it. Or is there not allowed to be any proprietary software in the

Re: Why unknown?

Matthew Woehlke wrote: Andreas Schwab wrote: What is a PC anyway? Is a 32 cpu system a PC? ...anything x86 or x86_64 architecture. So is this: http://unisys.com/products/enterprise__servers/high_d_end__servers/features.htm a PC, then?

Re: Checking for GCC 4

E. Rosten wrote: There are some reasons for doing this (bigish changes in standards compliance in g++ 4 compared to g++ 3) Reasons, yes. Good reasons, no. What happens when GCC 4.1 comes out, and we find that it has still more standards restrictions, just as every point release since 3.0

Re: Failure to use -lnsl on Solaris with AC_CHECK_LIB

Stepan Kasal wrote: Warren, will you please update the Autoconf Macro Archive? Done. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: Failure to use -lnsl on Solaris with AC_CHECK_LIB

Russ Allbery wrote: AC_SEARCH_LIBS([gethostbyname], [nsl]) AC_SEARCH_LIBS([socket], [socket], , [AC_CHECK_LIB([nsl], [socket], LIBS=$LIBS -lsocket -lnsl, , -lsocket)]) A macro based on this code is now in the Autoconf Macro Archive:

Failure to use -lnsl on Solaris with AC_CHECK_LIB

only. dnl dnl @version 1.1, 2005/02/28 dnl @author Warren Young [EMAIL PROTECTED] AC_DEFUN([MYSQL_API_LOCATION], [ # # Set up configure script macros # AC_ARG_WITH(mysql, [ --with-mysql=path root directory path of MySQL installation

Re: Failure to use -lnsl on Solaris with AC_CHECK_LIB

Russ Allbery wrote: Well, Autoconf has never handled this automatically for anyone else. :) I don't do any specific checks for libnsl currently, yet it gets linked automatically when build the program on Linux, at least. How is that need discovered, if not automatically by autoconf? I

Overriding PACKAGE_TARNAME?

I maintain a package called MySQL++, which uses autoconf. In previous versions of the library, we used AM_INIT_AUTOMAKE, calling the package 'mysql++'. For the upcoming version of the library, we have switched over to the newer AC_INIT syntax. But now, 'make dist' is creating tarballs

Re: Overriding PACKAGE_TARNAME?

Ralf Wildenhues wrote: AC_INIT([MySQL++], [1.2345], [EMAIL PROTECTED], [mysql++]) Ah, thank you. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: autoconf and STL

Bob Friesenhahn wrote: It seems to me that the vast majority of C++ compilers currently in use provide a working version of the STL library. As maintainer of MySQL++ (which relies heavily on STL), I agree. GCC has taken over the POSIX world in recent years, and the remaining compilers

Re: autoconf hardware

Dirk wrote: how can i make autoconf probe for a parallel port? Any particular OS, or all of them? :) On a Linux box, I'd probably dig around in /proc to find a way to list parallel ports and then write the shell code necessary to make sure the /proc entry exists and contains the expected

Re: check for microsoft compiler cl

Paul Eggert wrote: I assume so, but you may have to consult a Cygwin mailing list. No, _don't_ bother the Cygwin mailing lists about Visual C++ problems. _Way_ inappropriate forum; they'll tell you to use gcc, which auto* will use without any problems. Johannes, if you're just changing the

Re: --with-foo= vs. FOO=${FOO:-foo_default}

Troy Cauble wrote: I'm porting a large, full-featured, autoconf-based project to an embedded linux system where certain features cannot be supported. The C/C++ files will require a -D flag to control some ifdefs. The Makefile.am's will require either ifeq statements or MY_FLAGS style

Re: Learning Autoconf

Ryan T. Sammartino wrote: You will not find better material than this book to learn about the GNU Build System. I second that. I went from zero Autotools knowledge to a Zen master with this book (well... almost :) ). I'll third it. I procrastinated learning the autotools until I

Removing -O2 from CFLAGS

It seems that autoconf always adds -O2 to its build lines. I have a compiler that generates bad code for a particular program when built with -O2, so I'd like to turn that flag off. I can use AM_CFLAGS to _add_ flags like -O0, but that gets subbed in _before_ the default flags so -O2 overrides

I don't understand test caching

I'm an autoconf newbie. I have a few working autoconf macros that I tried to add caching support for, on the model of code from the Vaughan et al. autobook. Caching sort of works: I can see the proper value set in config.cache, and on the first clean run the appropriate #define gets set in