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:
>
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_failure_modes_and_how_to_fix_them
All the examples in the video are a result of targets underspecifying their
On Sun, Jan 31, 2021 at 10:14:11PM +, Gavin Smith wrote:
> Another issue is how to record the results of tests from a a Makefile.
> With autoconf, autoconf variables are recorded with AC_CONFIG_FILES
> and AC_CONFIG_HEADERS. Presumably the same would have to be done,
> substituting in an
On Mon, Jan 25, 2021 at 03:15:47PM -0800, Paul Eggert wrote:
> On 1/25/21 2:59 PM, Gavin Smith wrote:
> > Does this
> > work or does GNU make have other ways of doing this? (It would be
> > better if it could be done without communicating via files.) Is there
> > any way to set a Makefile
On Wed, 2021-01-27 at 18:26 +, Joseph Myers wrote:
> On Wed, 27 Jan 2021, Richard Purdie wrote:
>
> > Thanks, I hadn't realised. The only two recipes we never autoreconf are
> > binutils and gcc, instead we do some painful things to handle libtool
> > issues so we get our libtool tweaks. It
I'd just like to suggest that in the event of future significant
development on a new automake, or a revamped build system in whatever
way, that the new system not be called "autoconf" or "automake".
It seems inevitable to me that any such new system would have
incompatibilities with the old, and
On Wed, 27 Jan 2021, Richard Purdie wrote:
> Thanks, I hadn't realised. The only two recipes we never autoreconf are
> binutils and gcc, instead we do some painful things to handle libtool
> issues so we get our libtool tweaks. It sounds like we should revisit
> that. I guess we were so used to
On Wed, 2021-01-27 at 00:49 +, Joseph Myers wrote:
> On Tue, 26 Jan 2021, Richard Purdie wrote:
>
> > I've also not seen mention of it but the fact that GCC and the
> > toolchain use an ancient version of autoconf has always been rather sad
> > to me.
>
> I moved GCC from 2.64 to 2.69 in
On Tue, 26 Jan 2021, Richard Purdie wrote:
> I've also not seen mention of it but the fact that GCC and the
> toolchain use an ancient version of autoconf has always been rather sad
> to me.
I moved GCC from 2.64 to 2.69 in 2018 (building on Simon Marchi's
implementation of the same move for
Firstly, thanks for the 2.70 release! Yocto Project hasn't switched yet
as whilst we tested it and reported issues, there was a last minute
change which broke things for us. We'll get that sorted and upgrade.
I am one of the lead developers of the Yocto Project and at its heart
is OpenEmbedded
On Mon, 2021-01-25 at 17:48 -0500, Nick Bowler wrote:
> But for me, I want my packages to be widely portable and out-of-the-
> box compatibility with default "make" implementations, to the
> greatest extent possible, on a wide variety of real-world platforms
> is important.
I understand, but
On Tue, 2021-01-26 at 11:01 -0800, Andy Tai wrote:
> GNU Make integrates with guile. Maybe such extension can be
> done using guile for flexibility?
The problem is that hardly any standard distributions build GNU make
with Guile support enabled. If this was used basically it would end up
GNU Make integrates with guile. Maybe such extension can be done
using guile for flexibility?
(ref:
https://www.gnu.org/software/make/manual/html_node/Guile-Integration.html#Guile-Integration)
On Thu, Jan 21, 2021 at 12:11 PM Paul Eggert wrote:
>
> One possible way forward is to have an
On 1/25/21 2:59 PM, Gavin Smith wrote:
Does this
work or does GNU make have other ways of doing this? (It would be
better if it could be done without communicating via files.) Is there
any way to set a Makefile variable from within a rule and then depend upon
that variable being set in other
On Mon, Jan 25, 2021 at 10:59 PM Gavin Smith wrote:
> storing the value that should be in CC in the file CC.conf. Does this
> work or does GNU make have other ways of doing this? (It would be
> better if it could be done without communicating via files.) Is there
> any way to set a Makefile
On Mon, Jan 25, 2021 at 02:10:01PM -0800, Paul Eggert wrote:
> On 1/25/21 5:37 AM, Paul Smith wrote:
> > The only thing that would make much of a performance difference, I
> > think, is if we are able to replace lots of shell invocations with
> > built-in make functions like wildcard, if, etc.
>
On 2021-01-25, John Calcote wrote:
> On Mon, Jan 25, 2021 at 12:26 PM Nick Bowler wrote:
>> On 2021-01-25, Zack Weinberg wrote:
>> > I'm not at all familiar with Automake's internals, but the reason I
>> > suggested taking advantage of GNU make extensions was the potential
>> > for _complexity_
On Mon, 25 Jan 2021, Paul Eggert wrote:
On 1/25/21 5:37 AM, Paul Smith wrote:
The only thing that would make much of a performance difference, I
think, is if we are able to replace lots of shell invocations with
built-in make functions like wildcard, if, etc.
One other thing could be a
On 1/25/21 5:37 AM, Paul Smith wrote:
The only thing that would make much of a performance difference, I
think, is if we are able to replace lots of shell invocations with
built-in make functions like wildcard, if, etc.
One other thing could be a significant performance win: if we could use
On Mon, 25 Jan 2021, John Calcote wrote:
To be honest if Automake-generated Makefile.in files only worked
for users with, say, sufficiently modern versions of GNU Make, I'm
not sure there would be any point in using Automake.
I'm not sure I see your point Nick. Why use Automake? Because I'd
On Mon, 25 Jan 2021, Zack Weinberg wrote:
and enable Make to bypass the shell altogether. Might be worth
benchmarking on a big program. Has to be an executable, not a
library, though; for libraries, the overhead of the libtool script is
going to dominate.
As a reminder, a former Automake
On Mon, 2021-01-25 at 13:27 -0700, John Calcote wrote:
> > To be honest if Automake-generated Makefile.in files only worked
> > for users with, say, sufficiently modern versions of GNU Make, I'm
> > not sure there would be any point in using Automake.
>
> I'm not sure I see your point Nick. Why
On Mon, Jan 25, 2021 at 12:26 PM Nick Bowler wrote:
> On 2021-01-25, Zack Weinberg wrote:
> > I'm not at all familiar with Automake's internals, but the reason I
> > suggested taking advantage of GNU make extensions was the potential
> > for _complexity_ reduction of the generated Makefile, not
On 2021-01-25, Zack Weinberg wrote:
> I'm not at all familiar with Automake's internals, but the reason I
> suggested taking advantage of GNU make extensions was the potential
> for _complexity_ reduction of the generated Makefile, not performance.
> For instance, this generated rule from one of
Zack, thanks for the interesting analysis.
In the *short* term, I think “create a CI system” is the critical first step.
Since the autotools are all about supporting many platforms, if possible that
infrastructure should support VMs with many different targets (many Linuxes,
MacOS, Windows,
On Mon, 2021-01-25 at 09:47 -0500, Zack Weinberg wrote:
> I'm not at all familiar with Automake's internals, but the reason I
> suggested taking advantage of GNU make extensions was the potential
> for _complexity_ reduction of the generated Makefile, not
> performance.
Oh yes, there's absolutely
On Mon, Jan 25, 2021 at 8:38 AM Paul Smith wrote:
> On Sun, 2021-01-24 at 16:26 -0700, Tom Tromey wrote:
> > I think it would be good. I'm curious if it is known to be faster or
> > if that's just an expectation. I'd also be very interested to learn
> > which changes would make the result
On Sun, 2021-01-24 at 16:26 -0700, Tom Tromey wrote:
> I think it would be good. I'm curious if it is known to be faster or
> if that's just an expectation. I'd also be very interested to learn
> which changes would make the result faster.
Speaking for myself I'm not convinced requiring GNU
> One is that perhaps autoconf, automake, and libtool (but see below)
> should be combined into a single project. This would help eliminate the
> coordination problem.
John> I personally love the idea of combining the projects so we no
John> longer have these inter-project release issues, and
On 1/22/21 2:48 PM, Nick Bowler wrote:
I don't have enough experience with Meson to say. Mainstream free
software packages have only very recently started using it. On the
GNU side, glib-2.60 (ca. 2019) converted to meson and I am able to
build it. If possible, I will have to try again in
As always, thanks for all your effort Zack!
I wanted to share some of my thoughts on Autoconf and friends. Maybe I
wrote too much.
For me the most important requirement of the GNU build system is that
it must be as straightforward as possible for novice users to build free
software packages
On Thu, Jan 21, 2021 at 4:09 PM Tom Tromey wrote:
> Zack> Now we've all had a while to recover from the long-awaited Autoconf
> Zack> 2.70 release, I'd like to start a conversation about where the
> Zack> Autotools in general might be going in the future. Clearly any
> future
> Zack>
Zack> Now we've all had a while to recover from the long-awaited Autoconf
Zack> 2.70 release, I'd like to start a conversation about where the
Zack> Autotools in general might be going in the future. Clearly any future
Zack> development depends on finding people who will do the work, but before
On 1/21/21 8:01 AM, Zack Weinberg wrote:
I know that
at least one person has tried to write a set of GNU Make library files
intended to replace it altogether, but I've never seen anyone *finish*
that project. I'd very much like to see someone give that another go.
GNU Emacs never used
My two cents:
the competing build systems, cmake, meson, have in their "features" (and
major motivation for their original development) of supporting Xcode and
Microsoft Visual Studio. Supporting for these seem to become necessary for
GNU Autotools to compete, even if these two may be outside
On Wed, 20 Jan 2021, Nate Bargmann wrote:
Thanks for your effort over this past year, Zack. As a user of
Autoconf, your work, as is that of all contributors, is much
appreciated.
One strength of the Autotools that I think stands above the rest is the
fact that a user of a distributed package
Zack Weinberg wrote:
> - A linter for configure.ac and third-party macro libraries.
> This wouldn't be any fun to write, because it would have to parse
> both M4 and shell, *accurately*, but it would be valuable to every
> user of autoconf.
Fortunately, free versions of both parsers
Zack,
On Thu, Jan 21, 2021 at 9:12 AM Zack Weinberg wrote:
> On Wed, Jan 20, 2021 at 5:15 PM Zack Weinberg wrote:
> > Now we've all had a while to recover from the long-awaited Autoconf
> > 2.70 release, I'd like to start a conversation about where the
> > Autotools in general might be going
On Thu, Jan 21, 2021 at 11:01:34AM -0500, Zack Weinberg wrote:
> Having said that, switching to *anything else* would be a gigantic
> task -- multiple full-time person-years of effort just for the core --
> and would mean either porting or losing all of the third-party macro
> libraries. I don't
On Wed, Jan 20, 2021 at 5:15 PM Zack Weinberg wrote:
> Now we've all had a while to recover from the long-awaited Autoconf
> 2.70 release, I'd like to start a conversation about where the
> Autotools in general might be going in the future.
> Now we've all had a while to recover from the
Thanks for your effort over this past year, Zack. As a user of
Autoconf, your work, as is that of all contributors, is much
appreciated.
One strength of the Autotools that I think stands above the rest is the
fact that a user of a distributed package does not need to install any
of the Autotools
On Wed, 2021-01-20 at 17:15 -0500, Zack Weinberg wrote:
> As a starting point, I wrote up a "strengths, weaknesses,
> opportunities, and threats" analysis for Autotools -- this is a
> standard project management technique, if you're not familiar with
> it, there's a nice writeup in the draft of
* On 2021 20 Jan 17:33 -0600, Bob Friesenhahn wrote:
> Autotools is in great danger of becoming irrelevant, at least for new
> software development. A lot of people feel hostile toward it.
This is quite true.
As a co-maintainer of a library project that uses Autoconf, Automake,
and Libtool,
(Removing automake as the original message said "Followup discussion
should go to the Autoconf mailing list.")
I agree that consolidating support for the current architecture and
use cases is the place to start.
The number one screaming priority would seem to be adding continuous
integration.
It seems better not to start another language. with already lack of
resources, that will further dilate available resources, and hard to
compete with other tools already us9ng Python's mature ecosystem
On Wed, Jan 20, 2021 at 3:32 PM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
>
> In
On Wed, 20 Jan 2021, Zack Weinberg wrote:
Now we've all had a while to recover from the long-awaited Autoconf
2.70 release, I'd like to start a conversation about where the
Autotools in general might be going in the future. Clearly any future
development depends on finding people who will do
Thanks for writing all of this.
I'm writing from the perspective of a long-term user of the autotools.
A discussion like the one you have started will likely attract many
opinions. Some will be contradictory. However, somebody in the end
will have to decide.
The challenge seems to be to evolve
Nice writeup!
Next step might be to set up continuous integration for Autotools,
with automated testing on the core list of supported platforms, and
use that to do a nearly-no-change release that just fixes any bugs
that show up by the time it's working.
I have no time and cannot plausibly
Now we've all had a while to recover from the long-awaited Autoconf
2.70 release, I'd like to start a conversation about where the
Autotools in general might be going in the future. Clearly any future
development depends on finding people who will do the work, but before
we worry about that I
49 matches
Mail list logo
