* 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 much > to become expert at in order for new volunteers to make an impact. The same > is true for libtool. > > 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 'awk' > or other things which can be implemented internally in a way which does not > 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. > > Regardless, thanks for your ideas and the red alert. Agreed on both of these counts, Bob. - Nate -- "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
Attachment:
signature.asc
Description: PGP signature
