LWN: Comments on "Rejuvenating Autoconf"

Rejuvenating Autoconf

IDog1993 — Sun, 23 May 2021 22:26:55 +0000

Everything ages and every cathedral crumbles into a bazaar eventually. So thanks to those who support tools such as autoconf that help keep bazaar open, even if it is with sticky tape and bits of string. Developers tend to work with the latest and greatest gizmos and so do not appreciate the difficulty of others who are running just to keep up. Almost every piece of hardware and software I have owned since the late 1980's has died of terminal bit-rot. Now my cloud hosts are entering end-of-life and similarly dying of bit-rot and I am porting again. So the safest strategy seems to be to be a continual platform nomad and grind one's software into a hardened portable core. Which means using autoconf but continually refactoring to eliminate the need for working feature tests.

Ask (1) would be for all the conftest source code to be available as separate standalone source files, so they are reusable - backporting a standalone minimal working example of a test for a working or not-working feature into an M4 macro and testing working and not-working configurations across platforms is a chore - these little conftests should be passed around, maybe even as a separate package - a sort of sub-autoconf-archive. They should naturally pop out of regression testing - they would be re-usable in test cases and could be used for probing configurations before starting on coding a packaging. I've been working today on testing for a regression in a third-party library and trying to work out the best way of preventing bug testing cruft and work arounds from clogging up the build system and the source code. With shell scripts I have started providing a unconfigured Posix version and an autoconf configurable version - I test for compliance and then choose to use a compliant or configured script - rather than making all scripts configurable - this is to keep the old cruft in a separate box. I haven't noticed bugs becoming less common, so testing for them remains a forever problem. Perhaps viewing new features as bugs too would help.

Ask (2) would be for a clearer separation in the documentation of (a) bug tests (or "works" tests), from (b) user choices, from (c) probing system configuration. And more complete examples of how a bug test at configuration leads through to beautiful source code and build configuration with all the cruft hidden in a separate box.

Ask (3) would be more supporting tools to test for portability and compliance - the autoconf documentation on portability is very good but at every turn there is the temptation to slip into using the --new-magic option which just needs a tiny, tiny upgrade - go on you know it will be good for you. Tests for new so called features are an excellent way of spotting a, possibly unnecessary, upgrade dependency. And GNU tie-in is also a portability issue just like any other - copy-left is fine, but not at the expense of freedom from GNU too.

Ask (4) for autoconf would be the ability for all autoconf files to be out of the project root folder (except perhaps one file with GNU in the name) - with packages now shipping with multiple build systems all hogging the project root folder there are more build system files than sources lying around.

2.70 release and followup analysis

sumanah — Thu, 21 Jan 2021 20:55:49 +0000

Autoconf 2.70 came out in December 2020 and Zack Weinberg has written up an analysis to help guide future investment in and development of the GNU Autotools. Conversation has ensued on the Autoconf mailing list.

Rejuvenating Autoconf

immibis — Tue, 12 Jan 2021 20:13:46 +0000

a.k.a. XKCD 927

Rejuvenating Autoconf

wtarreau — Sat, 02 Jan 2021 06:19:59 +0000

No it's not an error to respect end users' setups, and is actually a sign showing a project that cares about being smooth to use.

I used to hate cmake when I discovered it in early projects because it used to be associated with systematic failures. Cmake improved, and projects learned to use it correctly, and over time I started to notice that the usual "mkdir build && cd build && cmake .. && make -j$(nproc)" worked almost every time. One old grief was on cross-compilation but nowadays it seems to work smoothly (though it's often hard to remember the variable names to set the target). Initially I used to have to upgrade cmake by hand everytime I needed to build a project, but nowadays I don't know what version is installed here but it works. *This* is part of the project's success: developers just have to be reasonable with the minimum version they expect, and for users it always works.

So kudos to the developers for keeping that great a care for backwards compatibility. This is essential for a project's success as it's the only way to avoid in-field fragmentation (hint: anyone still has python2 installed to run esptool.py, luatool.py or whatever script not compatible with python3?).

Rejuvenating Autoconf

oldtomas — Sun, 13 Dec 2020 11:12:37 +0000

Funny. 3.1 is about the last (and probably only) Windows I had some intimate contact with (writing C).

This was the version where the provided editor (yah, it was called Notepad!) couldn't load windows.h due to some 16 bit limitation.

And yay, Hungarian Notation.

I think that's why I cringe these days when someone calls his shell script "foo.sh". Post traumatical thingmajig. Or something.

Thank you, Autotools!

oldtomas — Fri, 11 Dec 2020 10:00:27 +0000

And thank you, Sumana Harihareswara.

Contrary to many commenters around here who seem in dire need to vent some unspecified frustration, many of my projects are long-term.

As an example, one customer has some GUI program (Gtk2, started roughly twenty years ago). It still runs at the customer's premises. Every five years or so they come back with some enhancement requests.

Its build system, Autotools, led me through stand-alone compile to Debian package build, to Debian cross-build for foreign architectures. It never let me down. It Just Friggin' Works (TM).

Yes, it took some investment to set up, but from then on it was basically hassle free.

Sorry, you CMake, SCons, I-Build-It and diverse Harbor-Freight-Build system folks, but I just don't believe you that your favourite build system would have served my customer and me so reliably and noiselessly.

My next project? Autotools. Hands down.

Some of you may call that Frankenstein's monster. If that be so, I ♥♥♥ you, Frankie.

Rejuvenating Autoconf

sandsmark — Wed, 09 Dec 2020 09:31:29 +0000

> I've been mulling over creating a project that takes a compile_commands.json as input and generates a meson.build from it. The idea would be to make migrations to meson at least partially automated. It might even be possible to generate multiple different compile_commands.json with build options and generate a meson.build with those same options.

In my experience, tools like that tend to lead to more work in the end with having to clean up everything. It's usually better to at least start those kinds of transformations from the simplest representation (i. e. so you don't have to manually pattern match a bunch of compile options etc.), and even then I end up realizing I should have just started from scratch at the endi.

Even just generating a list of source files to build would lose any kind of grouping or similar (and miss files that are built conditionally).

And FWIW, because KDE has replaced the build system a couple of times there are some scripts that are/were used to create a starting point for porting from e. g. automake to cmake, here's one of them (not sure if it is useful for doing the same conversion to meson for non-KDE projects though): https://invent.kde.org/sdk/kde-dev-scripts/-/blob/master/...

Rejuvenating Autoconf

nix — Sat, 21 Nov 2020 13:08:05 +0000

Yeah, we're not talking modern Windows though. I'm fairly sure back in the days when I did stuff on Windows 3.1 that the whole import library mess more or less precluded intra-DLL dependencies. (But then 16-bit Windows DLLs were *weird* things.)

Rejuvenating Autoconf

Cyberax — Fri, 20 Nov 2020 22:42:06 +0000

> .la files are for lesser platforms like Windows and AIX which don't allow shared libraries to depend on other shared libraries
Windows shared libraries most definitely can depend on other libraries. Although circular dependencies are not allowed.

Rejuvenating Autoconf

nix — Fri, 20 Nov 2020 21:55:45 +0000

.la files are for lesser platforms like Windows and AIX which don't allow shared libraries to depend on other shared libraries, and also for static libraries: they make .a files into something that, like shared libraries, you only need to specify -l for once, when you build it.

These days the lesser platforms are mostly extinct and hardly anyone builds static libs any more unless absolutely unavoidable, so .la files are of much less use than in days gone by.

Rejuvenating Autoconf

nix — Fri, 20 Nov 2020 21:51:11 +0000

That hasn't been true for years. You've needed a C++98 compiler to compile all GCCs since, IIRC, 4.8.

Rejuvenating Autoconf

anton — Wed, 04 Nov 2020 11:53:31 +0000

Gforth is not a commercial project, either. That's why it supports portability beyond commercial considerations (e.g., 8 architectures were successfully tested on the latest release); by contrast, the most widely ported current commercial Forth implementation supports only IA-32, AMD64 (in development), ARM (32-bit) on mainstream OSs, and some embedded systems.

Considering Ubuntu 12.04 (the then-current LTS release) obsolete in December 2012 is a pretty strong sign of disdain for maintaining compatibility with old stuff, actually even with then-current stuff.

My "unusual browser configuration" is to heed the web page's requests for fonts and colours. The Meson developers invested a bit of their "minimal" staffing to ask for a tiny font and for light-gray-on-dark-gray colours. After working around that, the content is readable, but not worth reading.

Rejuvenating Autoconf

anton — Wed, 04 Nov 2020 11:23:19 +0000

There is nothing language-specific about make or the basic functionality of autoconf. Autoconf comes with macros specific for shell, make, and C and C++ libraries, but you can also address other portability problems in this framework, e.g., whether m4 understands the "-s" flag, or how to skip 16 bytes of code space in assembly language (Gforth does both of this).

Rejuvenating Autoconf

marcH — Tue, 03 Nov 2020 20:24:37 +0000

In an ideal world yes it would be great to have a single polyglot build system that handles all programming languages. Of course it would not solve all linguistic problems, see GC discussion thread elsewhere on this page, but at least you would not have learn a new build system for each language.

In the real world you tend to only get build systems that "speak" a very small number of languages well... if any well at all. That's why most new languages come with some specialized build system. Admittedly sad but it lets them focus on providing more for their particular language. Also lets some of them not get distracted by "translation unit" conceptual limitations from the 70s or the utterly inconsistent mess of C toolchains.

Maybe some modular/plugin based architecture could do but good luck getting manpower for something like this - assuming it's even possible.

> Anyway, this has nothing to do with autoconf,

Apologies for being off-topic, I didn't realize other build systems had nothing to do with autoconf.

Rejuvenating Autoconf

marcH — Tue, 03 Nov 2020 20:09:28 +0000

> I notice in many places, including your posting and the Meson design rationale a disdain for maintaining compatibility with old stuff.

I don't see any disdain at https://mesonbuild.com/Design-rationale.html#5-must-not-a... , just a trade-off because meson is not a well-funded, commercial project. Any other reference?

I love old stuff when bugs can be fixed cleanly where they are. My disdain is only for ugly workarounds - typically required by commercial and/or closed-source systems - unmaintenable wrapper and too many layers of indirection.

> Interestingly, the first look at the Meson design rationale page gave the right impression; I had to adjust fonts and colours before I found it visually readable. Usually such pages are not worth reading, and that page was no exception.

There seems to be fair number of projects who found meson documentation readable enough: https://news.ycombinator.com/item?id=24881897

The meson project is minimally "staffed" (which goes back to my initial comment) and last time I checked it was unsurprisingly not overstaffed with talented documentation experts. However it is very friendly to "drive-by" contributions so I bet they'll be delighted to accept fixes for your unusual browser configuration.

PS: I've met a surprising number of long-time open source hackers (even some famous ones) who have never used the "info" command. FWIW I do use it all the time.

Rejuvenating Autoconf

anton — Tue, 03 Nov 2020 18:21:10 +0000

No thanks for palliative care of a project that has cost gazillions of developers a lot of their time and some of their sanity

Autoconf has saved me a lot of time. The alternative would have been to manually edit Makefile, config.h etc. for every platform we build on.

the problems solved by autotools have mostly disappeared

The problems are still there. If you don't want your project to be portable between platforms, nobody is forcing you to use autoconf. Gforth has portability as one of its goals, and thanks to autoconf previous releases have been portable to a wide range of OSs and CPU architectures, and we certainly want to stay portable (although admittedly we can no longer test on as many platforms as we used to).

I notice in many places, including your posting and the Meson design rationale a disdain for maintaining compatibility with old stuff. If everybody followed this principle, the software you use now would soon stop working; ok, so you get the new version (if there is one), but that would of course work differently than you are used to, so you have to change everything that you built that relies on it.

Interestingly, the first look at the Meson design rationale page gave the right impression; I had to adjust fonts and colours before I found it visually readable. Usually such pages are not worth reading, and that page was no exception.

Rejuvenating Autoconf

anton — Tue, 03 Nov 2020 17:20:43 +0000

With hindsight I think it's become clear that designing a language _without_ designing a companion build system was a mistake.

Given that many projects use multiple languages, designing build systems for a language is a mistake. E.g., automake is (or at least was, when we tried) useless for Gforth, because it does (did?) not offer anything for the non-C parts of Gforth, and was not worth the trouble for the C parts.

Anyway, this has nothing to do with autoconf, which is very useful for dealing with portability problems. It's great that it is being maintained.

Rejuvenating Autoconf

massimiliano — Tue, 03 Nov 2020 08:04:56 +0000

Hi!
You are correct, but with a nitpick :-)

In particular Unity doesn't use Android GC because it needed something to support XBox before Android become a thing and XBox implies CLR.

That's not strictly true.

Unity picked Mono as runtime for technical reasons way before the Xbox360 even existed.
They had a contract so that they could use the source and embed it everywhere, it was efficient, it supported popular languages (C#), it was easy to make it support more languages (just compile them into .NET CIL), and it was very portable so they could port their runtime (the whole Unity game engine) just about anywhere, which is what they did.

This technical choice predated everything else: in the very beginning Unity was Mac-only, even the Windows port happened later. And with hindsight, it has been a good choice, given the success they had.

About "GC in GC" nightmares, you forgot another realistic scenario: take a Unity game (Mono GC) with a Golang plugin (Go GC) and run it inside the browser using the WASM target.
Now you do not have three GCs "side by side", you have two side by side (Mono and Golang) running in a memory segment inside another GC (Javascript)!

Disclaimer: I have been working for the Mono project for almost six years, and after that for Unity for one year, among other things porting the Mono build toolchain to target the Xbox360, so I know all the above first hand.

Rejuvenating Autoconf

marcH — Mon, 02 Nov 2020 17:01:07 +0000

The sunk cost fallacy is by definition subconscious and it's a natural tendency we all have. This is very far from attributing a very specific, made-up point to someone specific.

> The sunk cost fallacy is when you choose not to switch to a cheaper option, because of what you've spend on the more expensive option.

The sunk cost fallacy is subconsciously give value to something that has none anymore and let that influence you. Influence is not always enough to win an (often collective) decision.

Sunk costs are much complicated in software than in say finance because _knowledge_ of an existing system is valuable: it makes knowledgeable workers much more productive which is of course very valuable, especially from the perspective of the experts. But what about the value for the project as a whole? The value of newer build systems is of a completely different sort: they require less expert knowledge and many more people can and do help with their maintenance. Interestingly, this decreases the "market" value of the old experts.

> It seems quite clear here that for many people, the cost of switching is very high, because they will have to (in one form or another) - reimplement a lot of autoconf. This makes maintaining autoconf the cheapest option!

It's pretty obvious that the minute after flipping the switch away from autoconf, a project that just migrated has spent a lot and gained nothing yet. I don't think anyone questioned that. Every technological choice is a large investment and its value must be studied _over time_.

Rejuvenating Autoconf

Wol — Mon, 02 Nov 2020 10:08:34 +0000

Except you are projecting YOUR values onto OTHER PEOPLE. *Bad* *Idea*.

The sunk cost fallacy is when you choose not to switch to a cheaper option, because of what you've spend on the more expensive option. It seems quite clear here that for many people, the cost of switching is very high, because they will have to (in one form or another) - reimplement a lot of autoconf. This makes maintaining autoconf the cheapest option!

Cheers,
Wol

Rejuvenating Autoconf

marcH — Mon, 02 Nov 2020 09:02:10 +0000

I'm afraid you lost me, sorry. In case that's relevant: "sunk cost fallacy" is _my_ perception of autoconf maintenance, has been long before this discussion and I didn't mean to attribute it to anyone else.

Rejuvenating Autoconf

marcH — Mon, 02 Nov 2020 03:13:22 +0000

Yes, all build systems suck. Today's build systems suck only one order of magnitude less. The main difference is: mere mortals can now wrap their head around their limitations, bugs and workarounds.

Rejuvenating Autoconf

ringerc — Mon, 02 Nov 2020 01:34:05 +0000

I'd agree with you if anyone, anywhere, had come up with a build system that wasn't awful... because the problem is awful.

The simple ones are beautiful until you step outside their design boundaries and want to do something they consider inappropriate. Like link to code that wasn't in turn built with the same build system or shipped with some kind of build system manifest file. Oh, the library maintainer should just ship a libfoo.whizzmagic !

The ones that don't try to pretend the world is simple and can be re-made afresh in their own vision tend to become mires of complexity, multiple outdated ways of doing things, stale documentation, and confusion.

Then some, like CMake, seem to manage to find the worst of both worlds, and still be pretty useful.

Rejuvenating Autoconf

jschrod — Sun, 01 Nov 2020 02:07:10 +0000

Sorry, but your "sunk cost fallacy" post the comment was about is exactly of your lamented "straw man" kind.

Pot, meet kettle.

Rejuvenating Autoconf

Cyberax — Sat, 31 Oct 2020 01:27:56 +0000

Hey, I remember using CMake 2.4! And being disappointed about being unable to use 2.6 because it had not been packaged in Debian.

Out of curiosity, I dug up that project and tried to build it with the most recent CMake. It actually worked with only a 2-line change! I love this stability.

Rejuvenating Autoconf

mathstuf — Sat, 31 Oct 2020 00:25:04 +0000

Yep, that we do. Story time :) . I wrote CMP0053 (new variable expansion code). I was all happy to be able to remove 5000+ lines of code for the old parser that used flex/bison for some strange reason. But, the old code had some silly behaviors we didn't want to preserve (e.g., didn't error on unknown escape sequences…just passed them on verbatim, unconditionally expanded `@var@` (who knew?), and some other silly things). Luckily the new one was fast enough to run both at the same time some we could warn when the new expansion code would differ in behavior from the old one without too much lost time.

The benefit from doing this stuff? CMake users can update CMake without fear that some subtle thing will break when they do so (I mean, it can, but we'll fix it if at all possible). Because you know what users with working build systems hate doing above almost anything else? Chasing subtle changes in behavior that breaks their build.

If you set your CMake minimum required to a sufficiently high version, it is an *error* to ask for the OLD behavior of any policy up to CMP0072 (introduced in 3.11) today (asking for OLD was convenience, never a supported mechanism to "upgrade" your project as the old behavior is, by definition, deprecated). These policies are effectively "hard deprecated" once your project's minimum is above 3.11 with modern CMake versions. You still can say you support, say 3.8, and you'll get the old behaviors though. CMake 4 is when any actual deletion would occur though, but I have no timeline for such a thing.

Rejuvenating Autoconf

jonesmz — Fri, 30 Oct 2020 22:04:49 +0000

Yikes. You have compat code going back to 2.6.0? That seems like a huge amount of human effort for questionable gain.

Do you have plans to eventually move that compat level forward and drop the 2.6.0 exclusive code paths?

Rejuvenating Autoconf

jonesmz — Fri, 30 Oct 2020 21:52:44 +0000

That seems to speak more to how horrible autotools is, than to how complex the GCC build system is.

Rejuvenating Autoconf

kpfleming — Fri, 30 Oct 2020 21:06:51 +0000

(putting on my Bloomberg hat)

Our involvement in this project came about via Python, actually. We're big users of Python, it's one of our three primary development languages (alongside C++ and JavaScript), and we employ and/or support quite a few developers in the Python community.

The team who wanted to do the work on Autoconf reached out to us specifically because we are big users of Python and CPython relies on autoconf for its portable configuration and build system, so it made sense that we might be interested in helping to improve it. We were, we agreed to provide some funding alongside others, and the result is what you see here.

While we do not have a formal program of funding open source development efforts, we are sponsors of a number of significant open source communities (including the Apache Software Foundation, Python Software Foundation, Outreachy, and more) and we do as much as we can to give back to the projects that produce the software we use.

Rejuvenating Autoconf

azz — Fri, 30 Oct 2020 17:24:55 +0000

As someone who uses autoconf and the other autotools dozens of times a day for a wide variety of projects (including some fairly hairy crossbuilding setups), I'd just like to say thanks for doing this work — I've always been very happy with the autotools, both as a developer and as a packger, and it's nice to see people making them even better.

Rejuvenating Autoconf

kmweber — Thu, 29 Oct 2020 23:07:33 +0000

So I'm curious--does Bloomberg have an ongoing program of funding free software development, or did they have an interest in autoconf (or the GNU build system and toolchain) specifically?

Rejuvenating Autoconf

sumanah — Thu, 29 Oct 2020 20:09:57 +0000

> I'm happy to see this work being done, and with Zack being involved I know the quality will be good.

Thank you. And I know what you mean! It's such a pleasure to work with Zack Weinberg on this; I am always glad to hear someone else also recognizing the consistent quality of his work.

Rejuvenating Autoconf

mathstuf — Thu, 29 Oct 2020 16:09:29 +0000

My favorite libtool tidbit is that I always have to nuke `*.la` files from install prefixes (distros do it to) because they tend to just…not work somehow. I know they break relocation since they bake the install prefix into the contents of files. What they're supposed to fix that makes them also somehow not important if they're missing is beyond me (I haven't investigated much other than knowing deletion is a viable solution).

Rejuvenating Autoconf

ecree — Thu, 29 Oct 2020 15:38:48 +0000

> Libtool could be deprecated, and have its features refactored into the faster and more integrated functionality in Automake.

Please don't. When I needed to create a shared library (libatg), I was able to figure out how to get libtool to do what I needed; whereas automake still gives me the screaming heebie-jeebies. All my projects build from a hand-written Makefile, and I'd like to retain that innocence.

Rejuvenating Autoconf

nathan — Thu, 29 Oct 2020 14:54:25 +0000

I'm happy to see this work being done, and with Zack being involved I know the quality will be good.

I use autoconf because I know how to drive it and it gets the job done. configurery goop is not the most exciting piece of development, so I'm not inclined to invest the time to learn some other DSL. Getting a nice explicit error that '$FOO is not available' is, IMHO, a much nicer user experience than an obscure build error or wrong code.

Rejuvenating Autoconf

mathstuf — Thu, 29 Oct 2020 00:54:47 +0000

> And, which I think is the really bad part, they don't even work when cmake fails with an error, for crying out loud.

Due to the nature of the options being defined in imperative code, there's no way for CMake to provide everything in the case of an error. On that front, the discussion around a declarative CMake might be of more use to you[1]. However, you will be able to edit what is available at least, so if you have an option that immediately causes an error, it should be in the cache (or at least in the error message assuming the project is nice enough to have good error messages) for editing.

> isn't a way to to run cmake in an existing build directory that ensures that only the -D parameters in the current invocation take effect

Without CMake knowing what the actual defaults are, this would be hard. It would be possible with the issue I linked to above once CMake does have the concept of `Option<UserSetting>`. I've added this idea to that issue[2], thanks.

[1]https://gitlab.kitware.com/cmake/cmake/-/issues/19891
[2]https://gitlab.kitware.com/cmake/cmake/-/issues/14756#not...

Rejuvenating Autoconf

andresfreund — Wed, 28 Oct 2020 22:51:58 +0000

Oh, another related issue: There - at least not that I have found - isn't a way to to run cmake in an existing build directory that ensures that only the -D parameters in the current invocation take effect (with the rest set their defaults). It's so easy to end up with options lingering around. Having to clean out the build tree is a pretty expensive solution...

Rejuvenating Autoconf

andresfreund — Wed, 28 Oct 2020 22:47:05 +0000

> I'm well aware of the discoverability problems of CMake's configure. A lot has been offloaded onto the cache editor UIs (ccmake and cmake-gui). One thing I'd personally like to see support for dumping out the (modified) settings for the current build (https://gitlab.kitware.com/cmake/cmake/-/issues/14756). This pretty much requires proper "use a default value" semantics in the `option` and `set(CACHE)` codepaths. The initial cache value is not a default as there's no tracking of whether the user wanted that explicitly or an old cache file is in use, so that is likely the first things that would need to be added.

Neither cmake-gui nor ccmake come even close to ./configure --help, unfortunately. They do not work without a build tree. And, which I think is the really bad part, they don't even work when cmake fails with an error, for crying out loud. Precisely when one might need to see the build options, to make the build succeed.

> CMake is also *extremely* strict about backwards compatibility. We still have codepaths laying around to act like CMake 2.6.0 if need be, so there should never be a reason to not use the latest CMake release for any project (please file bugs if this is not the case).

Will do that the next time I encounter it (which I hope is never...).

Rejuvenating Autoconf

mathstuf — Wed, 28 Oct 2020 21:49:23 +0000

> unlike "git archive" etc. you can control which files to exclude from being distributed and other things

The `export-ignore` attribute exists for this. `git archive` does suck at submodules, but just about everything does in practice anyways. `git archive-all` exists for those cases and handles a bad situation well enough (it is pure porcelain and is lacking plumbing for use in alternative automated tasks where it would be useful).

> it also creates tarballs with proper version number included in the tarball filename, can check that the ChangeLog file really has an entry for that version, etc. ...

Changelog strategies vary wildly from project to project. Some don't have them, some autogenerate them from commit logs (ugh), others are overly verbose to the point of uselessness (IMO, GCC is one of these).

> As basically most of this is in the Makefile template anyway it shouldn't be much of a problem for CMake to provide the same for the make backend, but somehow this never seems to have happened.

File an issue (or ping one that already exists). There's enough work that we don't actively seek out features to implement; it is mostly demand-driven. However, note that the Makefiles generator targets POSIX make, not GNU Make or any other specific flavor. Single-generator features also have a high bar for implementation (generally they need to be at least extremely difficult or specifically targeting that backend). I don't think making any "source tarball creation" built-in target would get over either bar, so it'd need to be available for any generator backend. But I think it is more CPack's wheelhouse anyways.

Rejuvenating Autoconf

hholzgra — Wed, 28 Oct 2020 19:25:18 +0000

> Autotools has the mechanisms to support out-of-source builds, but they're certainly not used
all the time.

yes, it can do it, but it is not advertised much, unlike CMake where it's the recommended method

> I think autotools gained that mechanism for itself because it
effectively patches the source for distribution in practice

unlike "git archive" etc. you can control which files to exclude from being distributed and other things

that's also one of the things the distcheck target checks for: does the build from the dist tarball fail due to any file missing from the dist tarball?

it also creates tarballs with proper version number included in the tarball filename, can check that the ChangeLog file really has an entry for that version, etc. ...

As basically most of this is in the Makefile template anyway it shouldn't be much of a problem for CMake to provide the same for the make backend, but somehow this never seems to have happened.