MESSAGE
DATE | 2021-01-20 |
FROM | Nate Bargmann
|
SUBJECT | Re: [Hangout - NYLXS] Future plans for Autotools
|
From hangout-bounces-at-nylxs.com Thu Jan 21 00:22:06 2021 Return-Path: X-Original-To: archive-at-mrbrklyn.com Delivered-To: archive-at-mrbrklyn.com Received: from www2.mrbrklyn.com (www2.mrbrklyn.com [96.57.23.82]) by mrbrklyn.com (Postfix) with ESMTP id 13472163FD6; Thu, 21 Jan 2021 00:22:06 -0500 (EST) X-Original-To: hangout-at-www2.mrbrklyn.com Delivered-To: hangout-at-www2.mrbrklyn.com Received: by mrbrklyn.com (Postfix, from userid 1000) id 16095163F5D; Thu, 21 Jan 2021 00:21:45 -0500 (EST) Resent-From: Ruben Safir Resent-Date: Thu, 21 Jan 2021 00:21:45 -0500 Resent-Message-ID: <20210121052145.GB11076-at-www2.mrbrklyn.com> Resent-To: hangout-at-mrbrklyn.com X-Original-To: ruben-at-mrbrklyn.com Delivered-To: ruben-at-mrbrklyn.com Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mrbrklyn.com (Postfix) with ESMTP id B5C9F163FCD for ; Wed, 20 Jan 2021 20:07:41 -0500 (EST) Received: from localhost ([::1]:60678 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2ORo-0003MS-PC for ruben-at-mrbrklyn.com; Wed, 20 Jan 2021 20:07:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55692) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2ORG-0003LS-Ud; Wed, 20 Jan 2021 20:07:07 -0500 Received: from www11.qth.com ([72.52.250.187]:51468) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2ORB-0007wV-RB; Wed, 20 Jan 2021 20:07:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=n0nb.us; s=default; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=CKfrm/yRURBN49L9r5hYeAiOgzq9VCnjQH4lVnXUTWs=; b=OaSgSEoLwHfCLE/qj/SuCrYdzw ATXwfT9dsHFnWx+SsHzJhiLGFOb/bKL0njWs8a5K5hwT4dtts4YmrG+qCk5yzkvitvsqBC5s1JEHA 6EOlu4fIm139c4QAdncA/Gj26UruwQGnz0cIxl0HnNQAFjF/NkoVtjs2wFp4UQbN0G4g=; Received: from [68.234.117.129] (port=40424 helo=merlin.lan) by www11.qth.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l2OR4-006CZy-1a; Wed, 20 Jan 2021 19:06:54 -0600 Received: from nate by merlin.lan with local (Exim 4.94) (envelope-from ) id 1l2OR3-001IMt-DD; Wed, 20 Jan 2021 19:06:53 -0600 Date: Wed, 20 Jan 2021 19:06:53 -0600 From: Nate Bargmann To: Autoconf , automake-at-gnu.org Message-ID: <20210121010653.mrgslrrdph3jy463-at-n0nb.us> X-Operating-System: Linux 5.10.0-1-amd64 x86_64 Organization: Amateur Radio! References: MIME-Version: 1.0 In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - www11.qth.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - n0nb.us X-Get-Message-Sender-Via: www11.qth.com: authenticated_id: n0nb-at-n0nb.us X-Authenticated-Sender: www11.qth.com: n0nb-at-n0nb.us Received-SPF: pass client-ip=72.52.250.187; envelope-from=n0nb-at-n0nb.us; helo=www11.qth.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: autoconf-at-gnu.org X-Mailman-Version: 2.1.23 Precedence: list Subject: Re: [Hangout - NYLXS] Future plans for Autotools X-BeenThere: hangout-at-nylxs.com List-Id: NYLXS Tech Talk and Politics List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2008291377==" Errors-To: hangout-bounces-at-nylxs.com Sender: "Hangout"
--===============2008291377== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x2carehrcahmoss4" Content-Disposition: inline
--x2carehrcahmoss4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
* 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, I've been asked point blank after the most recent major release why we have not switched to cmake. My answer was that I don't have the time nor the desire after spending a considerable amount of time getting my head around Autotools enough to improve and maintain the project's build system with a modicum of sanity. The project builds on any POSIX platform that Autotools can support and MS Windows. Portability of the build system is vital to this project and that is the second priority of the build system.
I've built projects from cmake and the Qt equivalent and while their build definition files often seem simple, it appears to me there is a lot that goes on behind the scenes. One strength of the Autotools is that Autoconf and Automake are almost infinitely malleable. Each supports dropping shell syntax in configure.ac or make syntax in a Makefile.am respectively. There just simply need to be ways for the project maintain to extend the build system in ways specific to that project. I've never cared to investigate cmake to know whether it is as capable thus I am unsure if cmake trades control for simplicity.
> It seems to me that Autoconf is too difficult to work on. There is too m= uch > to become expert at in order for new volunteers to make an impact. The s= ame > is true for libtool. >=20 > In my opinion, a new "language" designed specifically to meet the needs of > Autoconf should be developed and Autoconf should be re-implemented using = it. > There should be no more need to run external utilities like 'sed', or 'aw= k' > or other things which can be implemented internally in a way which does n= ot > suffer from the white space and delimiter issues that shell script does.
I'm not here to defend m4, on the contrary, my life would continue on just fine if I never had to look at m4 ever again. The very few times I have tried have not been pleasant. On the other hand, is there any enthusiasm for reimplementing sed, awk, or other such utilities since Perl did it over 30 years ago and other scripting languages have done so since?
The good thing about Automake is that though it is written in Perl, the implementation language doesn't seem to bleed through into the syntax of Makefile.am. With Autoconf, so long as the maintainer can stick with the provided macros or third party ones, life is tolerable. On the rare occasion that I started looking at enhancing a macro, I began questioning some life choices!
On the other hand, I am not so quick to abandon shell syntax. It is the lowest common denominator on POSIX like systems. That said, perhaps a reasonable approach would be to target a somewhat older POSIX specification and abandon support for shells that cannot reach even that low bar. As an aside, I have worked to ensure that any shell script that I write is free of Bashisms even though they can make writing scripts easier.
> It seems that the core precept that Automake should produce portable > makefiles should be re-evaluated if most systems provide GNU make, or can > easily be updated have it.
At the moment the project(s) that seem to be working toward replacing all things GNU do allow the later installation of GNU software. Will such projects eventually become hostile to even the premise of installing GPL software, let alone GNU software, ala iOS? If so, my concerns about support for other make implementations likely become moot as the project I'm involved with is GPL/LGPL licensed.
> There is a fork of Automake which was re-done to > be based on GNU Make. This assumes that makefiles written in GNU make can > noticeably improve things.
What negative impact would relying solely on GNU make have on third party projects intending to build on platforms where the installation of GNU make may become discouraged? While I've not read of any public plans of such, the actions of FreeBSD make me curious if they might head in that direction eventually.
> The support for 'distcheck' is excellent. >=20 > Regardless, thanks for your ideas and the red alert.
Agreed on both of these counts, Bob.
- Nate
--=20
"The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
--x2carehrcahmoss4 Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEG5vcSeqIHtMzWHg79yYl4u2+1ZgFAmAI060ACgkQ9yYl4u2+ 1ZhK0AwAqb1TlauKCTaOtB92jKYln1kiZQEVL2WZYDgWWqz2XnsECf3Tw72H8awP mNh2c561cJW/DV7inF7ELKZFCJ0hOdnB1RkzWh45zeE3VYk7u1BWNzfrfs2HuMwi sHH32HE5JkeR6THhRCNDpmpc2cFMC5sI4whKU9JvVtxnk8hHhlFblytmKfW/Saw3 63sNVRViRiZGSYFDlUSuSg1aQWLgpDvPDo4eXOS3P8BMtC3DUNVDDd/4qHuPaS6a vMiRZgoIso3Wz2OXt/Qz5Unbs1J3HKtzLX/DpZBt6o3ALBCGHfK3b4rgSgc0Letm P5/PdEoHe3OSU2B1JXdWY45J2vTJfT2bSGJK/BWPKe70UfNhuAqiLc+GM9Znxska 5yIjuQx/sU4QBRFo6Nl6BzW8BeIpmc1glJwpyvrxXfVEPLsVtMNoZDo3DWVnnE1+ NPN1RzlgXtmxduhqoaUkmMa0mdNvFpiFb709IrjYGYBkOGEqc4YYMvKPQxekeujS 4viXXyPt =WZcA -----END PGP SIGNATURE-----
--x2carehrcahmoss4--
--===============2008291377== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline
_______________________________________________ Hangout mailing list Hangout-at-nylxs.com http://lists.mrbrklyn.com/mailman/listinfo/hangout
--===============2008291377==--
|
|