On 2025-05-10 00:29:33, Jacob Bachmeyer wrote:
>
> Programs either no longer compile with a newer compiler or (worse)
> compile but with different semantics. I *think* Rust has only had the
> first of those problems, but have not followed the issue closely enough
> to be sure. Python infamous
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:
> https://media.ccc.de/v/camp2023-57415-fantastic_build_system_fail
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
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 m
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
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 p
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 i
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 __cplu
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 link
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 typing
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
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
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 a
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
> 71368maxres
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 configura
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
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
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
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 ./conf
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 "$as_
20 matches
Mail list logo
