[prev in list] [next in list] [prev in thread] [next in thread] 

List:       autoconf
Subject:    Re: Future plans for Autotools
From:       Eli Schwartz <eschwartz () archlinux ! org>
Date:       2021-01-22 21:01:18
Message-ID: 453c1c3e-7736-7ae4-e5ee-c369b44e9b72 () archlinux ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


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 2039.  I bet the
> autoconf-based glib-1.2.10 tarball from 2001 will still mostly work,
> and so will the 1996 version of GNU Bison.

Difficult to say, indeed.

I know this much, though. CMake seems to have this philosophy where 
build rules do different things depending on your version of cmake, and 
depending on which version that is, you *might* be able to specify 
https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html to go 
with the old or new behavior.

meson prefers to deprecate things that were decided "this is bad", and 
issue warnings maybe forever (I think it's been considered to drop 
deprecated, warning-raising functions for the 1.0 milestone? not 
guaranteed), then reimplement the better functionality as a new function 
or function keyword argument. The idea is specifically to avoid changing 
how old build files get processed. Instead, if developers want their 
builds to configure without big yellow warnings, they need to migrate to 
"the newer way".

Obviously this doesn't guarantee meson is always *successful* in being 
backwards-compatible. :)

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


["OpenPGP_signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]