automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future plans for Autotools


From: NightStrike
Subject: Re: Future plans for Autotools
Date: Thu, 6 May 2021 17:25:21 -0400

On Thu, May 6, 2021 at 4:44 PM Bob Friesenhahn
<bfriesen@simple.dallas.tx.us> wrote:
>
> On Thu, 6 May 2021, Karl Berry wrote:
> >
> > (*) https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html
> > So far the response has been nil.
>
> I don't recall seeing that email.  I did see an email thread regarding
> Autoconf which immediately became a lot of "need to support this soon"
> and "wouldn't it be nice" discussion, totally missing the point of the
> text they were reponding to (i.e. "project is on the gurney and may
> expire without help").
>
> Regardless, "baby bird" syndrome seems to be striking a great many
> established free software projects which are mature and heavily used.

I don't think it's fair to expect that a user of autotools is capable
of becoming expert enough in Perl to become a developer of autotools.

> Projects operated by billion dollar companies with teams of developers
> paid to sit in a cubicles and write free sofware seem to be doing
> fine.
>
> Unfortunately, this is not the model for most GNU projects.

I think this is a larger problem with companies tending to put support
into projects with licenses that they find more appealing.  For
instance, IMO, the GPLv3 provoked strong support for billion dollar
companies to latch on to llvm.

There is also a mindset shift with current developers.  The autotools
projects generally were guided by the idea of spreading GNU software
everywhere, and thus they take great care to, first and foremost, make
the job trivial for the person compiling the software at the expense
of more work on the side of the developer; and secondly, to support a
great many systems.  Whereas tools like CMake take a different
approach.  They aim to both support only a few systems
(comparatively), and they aim to make the job of the developer easier
while the job of the person compiling software becomes quite difficult
and cumbersome.

Said more simply, software from earlier days is better for "them",
while software from today is better for "us", for flexible definitions
of "them" and "us".

I don't particularly like the current trend.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]