Rejuvenating Autoconf

Posted Oct 27, 2020 18:44 UTC (Tue) by hholzgra (subscriber, #11737)
In reply to: Rejuvenating Autoconf by Cyberax
Parent article: Rejuvenating Autoconf

You can, even though it doesn't like it and will complain a little bit as far as I remember.

The problem is that you can have build rules that touch files in the source dir instead of build dir.

The autotools distcheck targets catches this by doing:

* creating a dist tarball
* unpacking that into a subdirectory
* changing that directory and its contents to read-only
* creating a build directory
* doing an out of source build
* AFAIR: doing "make test", too

This will, among other things, catch any file created or touched in sourcedir instead of destdir.

With CMake, at least the last time I dealt with it, this needed to be tested manually ...

(... and I remember several cases over the years where a build rule touching source dir files slipped in into MySQL / MariaDB and stayed undetected for extended periods of time)

Rejuvenating Autoconf

Posted Oct 27, 2020 18:55 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

This sounds like it's pretty easy to do with CMake, though. Maybe replace dist tarballs with checking hashes of directories instead.

Rejuvenating Autoconf

Posted Oct 28, 2020 16:07 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

I've certainly had to fix out-of-source builds with autotools myself (as it is something I tend to Just Do when building software these days; my history is riddled with `$OLDPWD/configure` calls). Autotools has the mechanisms to support out-of-source builds, but they're certainly not used all the time.

The steps that are done could be done with CMake as well, though not many projects use CMake to make their source tarballs (`git archive` is usually enough; I think autotools gained that mechanism for itself because it effectively patches the source for distribution in practice). I'd find it useful if the normal CMake (or any build tool!) procedures in distro builds would set the source directory as read-only and started filing bugs with projects about not supporting out-of-source builds.

Rejuvenating Autoconf

Posted Oct 28, 2020 19:25 UTC (Wed) by hholzgra (subscriber, #11737) [Link] (1 responses)

> 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.

Rejuvenating Autoconf

Posted Oct 28, 2020 21:49 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> 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.