Re: Future plans for Autotools

On Fri, 2023-12-29 at 03:59 +, Adam Faiz via Discussion list for the autoconf build system wrote: > Hi, > > I want to share an interesting perspective that's overlooked and something > that the Autotools is capable of fixing: >

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

On Mon, 2023-12-11 at 10:55 -0500, David A. Wheeler wrote: > All: > > Will the latest version of autoconf work by default when the compiler has > these options enabled?: > -Werror=implicit-int > -Werror=implicit-function-declaration > I think the two fixes we're waiting for in the next release

[sr #110612] Re-exec of $as_myself chooses wrong configure script from PATH

Follow-up Comment #2, sr#110612 (group autoconf): No problem. If I create, $ cat configure #!/bin/sh echo $0 in my home directory, then at least in bash and dash, the $PATH entry gets prepended to $0 when it is needed to resolve "configure": $ PATH=/home/mjo configure /home/mjo/configure $

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Thu, 2022-11-10 at 12:16 -0500, Zack Weinberg wrote: > > Nobody has a whole lot of time to work on Autoconf at present, but I > would like to ask, anyway, what Autoconf could potentially do to make > this transition easier. While everyone else is discussing big ideas, it would be helpful for

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

On Mon, 2022-06-13 at 15:39 -0700, Paul Eggert wrote: > > I've wanted something like this for *years* (I assigned a simpler > version to my undergraduates but of course it was too much to expect > them to implement it) and I hope some sort of parallelization like this > can get into production

Re: Extensions to M4sh

On Wed, 2022-05-04 at 08:17 -0700, Per Bothner wrote: > On 5/4/22 05:07, Michael Orlitzky wrote: > > The trade-off you get for writing m4 is that the build system produced > > by autotools doesn't require you to have autotools installed, and > > instead uses only a portab

Re: Extensions to M4sh

On Wed, 2022-05-04 at 06:00 -0400, Demi Marie Obenour wrote: > > Honestly, I feel like the autotools are dying. > They're feature-complete, up to support for some newer languages. > If I use Meson or CMake, I get solutions to all of these problems, > except perhaps IDE integration. And that

[sr #110612] Re-exec of $as_myself chooses wrong configure script from PATH

URL: Summary: Re-exec of $as_myself chooses wrong configure script from PATH Project: Autoconf Submitted by: mjo Submitted on: Sat 19 Feb 2022 01:07:39 AM UTC Category: None

Possible regression in AC_FC_WRAPPERS

Between autoconf-2.69 and autoconf-2.71, the test programs that AC_FC_WRAPPERS uses to determine its name-mangling scheme has changed. In 2.69, for example, we have #ifdef __cplusplus extern "C" #endif char foobar_ (); #ifdef FC_DUMMY_MAIN #ifndef FC_DUMMY_MAIN_EQ_F77 # ifdef

Re: How to autoconf figure out what library need to be linked to?

On Tue, 2021-03-30 at 11:47 -0500, Peng Yu wrote: > Hi, > > crypt(3) does not need -lcrypt on macOS, but need -lcrypt on Linux. > How does autoconf determine what library needs to be linked based on > the source code? Thanks. > AC_SEARCH_LIBS doesn't use the source code; instead it tries to

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

On Tue, 2021-03-09 at 14:11 -0700, Warren Young wrote: > > Solaris 10 dates from early 2005. We gave it 16 years of direct > support, and now it’s on a sort of “extended” support if you point > Autoconf configure scripts at a reasonable shell. > I didn't realize it was that "recent." I'm

Re: Autoconf 2.70 release status update as of 2020-11-02

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

autoconf-2.69c Gentoo tinderbox run

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

Re: Using @bindir@ etc. in C headers

On 6/5/20 6:57 AM, Florian Weimer wrote: > I would like to define macros containing the standard paths, like this: > > #define BINDIR "@bindir@" > > It does not work due to this code in lib/autoconf/general.m4 (which > appears to be predate DESTDIR support): > > ... > > Is there are generally

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

On 3/13/20 2:27 PM, Bob Friesenhahn wrote: > > /bin/dash > 8.31user 2.37system 0:10.22elapsed 104%CPU (0avgtext+0avgdata > 71316maxresident)k > 0inputs+30016outputs (0major+1529930minor)pagefaults 0swaps > > /bin/bash > 9.38user 3.07system 0:11.71elapsed 106%CPU (0avgtext+0avgdata >

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

On 3/12/20 4:53 PM, Zack Weinberg wrote: > > On further investigation, there is a concrete reason why autoconf 2.69 > prefers SHELL=/bin/bash to SHELL=/bin/dash, namely that dash doesn't > support $LINENO, necessitating a complicated and fragile workaround The $LINENO support in dash is

Re: Making Autoconf 2.70 happen in the near future

On 3/10/20 11:28 AM, Zack Weinberg wrote: > > Thanks for the suggestion! I have no experience with Gentoo myself > but I've made a note to look at doing this at some point. You say you > automatically regenerate the configure script for any package that > needs to patch the build system, but do

Re: Making Autoconf 2.70 happen in the near future

On 3/9/20 4:22 PM, Zack Weinberg wrote: > >I happen to know that these have particularly complicated configure >scripts. I will also cheerfully take suggestions for additional >packages to test in this manner. > Thanks for doing this. Two things might make Gentoo an attractive test

Re: Re-exec of $as_myself chooses wrong configure script from PATH

On 5/30/19 8:33 AM, Michael Orlitzky wrote: > > Is this something that can (should?) be fixed? > Ping, this should be reproducible. It's easy to work around, but is extremely perplexing to its victims (I spent several hours debugging, and I like to think I'm pretty good at this stuf

Re: Re-exec of $as_myself chooses wrong configure script from PATH

On 5/30/19 9:39 AM, Eric Blake wrote: > > Executing 'sh configure' should execute whatever 'configure' is first on > your PATH, which is not ./configure unless '.' is early in your PATH. Are you sure about this? I wouldn't swear to it, but a quick check of POSIX suggests that it should run

Re-exec of $as_myself chooses wrong configure script from PATH

In the configure scripts that I'm generating, I see the following variable assignment: # Find who we are. Look in the path if we contain no directory # separator. as_myself=... Later, this may be used to re-exec the configure script with a better shell, exec $CONFIG_SHELL $as_opts