Rejuvenating Autoconf [LWN.net]

Rejuvenating Autoconf

Posted Oct 24, 2020 11:15 UTC (Sat) by rzaa (guest, #130641) [Link] (4 responses)

I preferred this method

./configure --prefix=$HOME/.local/stow/progname_progversion && make && make install
cd $HOME/.local/stow/
stow progname_progversion

P.S.
https://www.gnu.org/software/stow/
:]

Rejuvenating Autoconf

Posted Oct 24, 2020 14:30 UTC (Sat) by felixfix (subscriber, #242) [Link]

There is sometimes a "make test" in there somewhere too.

I remember well the first time I installed anything with autoconf. It was like magic.

Rejuvenating Autoconf

Posted Oct 25, 2020 10:07 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

That should of course be

/configure --prefix=$HOME/.local && make && \
make install DESTDIR=/home./local/stow/progname_progversion
cd $HOME/.local/stow/
stow progname_progversion

(or make install prefix=... with a sufficiently old package)

The configure-time prefix is the prefix the package *runs* from, and only provides a default for the prefix it is installed to. Stowed packages do not run from their installation location: that's the whole point of stow...

Rejuvenating Autoconf

Posted Oct 25, 2020 19:38 UTC (Sun) by rzaa (guest, #130641) [Link] (1 responses)

Yeah, you are rigth.
I realized that I haven't used these prefixes correctly.

Rejuvenating Autoconf

Posted Oct 26, 2020 15:27 UTC (Mon) by nix (subscriber, #2304) [Link]

To be fair, many packages don't care: but as soon as you have one that needs to access stuff provided by other packages, you'll notice.

Rejuvenating Autoconf

Posted Oct 26, 2020 7:17 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

> Oh dear. That initial command line should be
>
> ./configure && make && make install

No, the usual way to use it, sadly, is still:

./configure || vi configure

This is why this tool is wrong by design.

Rejuvenating Autoconf

Posted Oct 27, 2020 10:42 UTC (Tue) by hholzgra (subscriber, #11737) [Link] (8 responses)

> ./configure && make && make install

The true power, on the developer side, only shows with

make distcheck

though.

Lack of this kind of end-to-end test is one of my main pain points with CMake, where it is all to easy to get things like out-of-source builds wrong.

(and don't get me started on CMake and "make uninstall" ...)

Rejuvenating Autoconf

Posted Oct 27, 2020 11:37 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> where it is all to easy to get things like out-of-source builds wrong.

Alas, yes, it is. The thing is that it's tribal knowledge and due to the way things interact, hard to document effectively (it comes back to our lack of guide-level documentation). One also has issues with projects being embeddable into others (alas, also a more common occurrence today) with assumptions about what the top-level project means and such.

> make uninstall

This is because CMake allows for arbitrary code during installation (`install(<CODE|SCRIPT>)`) which can easily escape `install_manifest.txt`'s view of things. I wish the "everything is via `install(<FILES|DIRECTORIES|TARGETS|EXPORT>)`" flag to indicate that `install_manifest.txt` is at least potentially trustworthy were easier to toggle though.

Rejuvenating Autoconf

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

> Lack of this kind of end-to-end test is one of my main pain points with CMake, where it is all to easy to get things like out-of-source builds wrong.
Uh... I'm pretty sure CMake always runs with out-of-tree builds. Can you even make it in-tree?

Rejuvenating Autoconf

Posted Oct 27, 2020 18:27 UTC (Tue) by madscientist (subscriber, #16861) [Link]

Sure. Works fine.

You can't have both in-tree and out-of-tree builds at the same time and you can't switch from in-tree to out-of-tree without a full clean first.

Rejuvenating Autoconf

Posted Oct 27, 2020 18:44 UTC (Tue) by hholzgra (subscriber, #11737) [Link] (4 responses)

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.