And now another rant about build systems, this time it's more accurately the state of upstream's repository.

The state of the repository

$ git clone git://git.savannah.gnu.org/screen.git
$ ls screen
COPYING  incoming  mktar.pl  patches  src

That's right, they keep patches in version control and the source code in a subdirectory.

This is pointlessly different, serving only to make it harder to build from version control. It's yet further fetishising of Tarballs.

I'm particularly annoyed by this because the Baserock build tool, morph, can automatically infer how to build something by which files are checked in to version control.

DESTDIR in the Makefile

As a bit of background, $DESTDIR is the traditional way for specify a directory to install to for packaging, instead of installing directly onto your system. You can then make a tarball of the contents of $DESTDIR, which you can later unpack onto many systems.

Then you get rules in your Makefile to install along the lines of install screen $(DESTDIR)$(bindir)/screen.

Baserock sets this environment variable during the install step, and tars it up.

Irritatingly, the Makefile specifies DESTDIR =, which means it overrides the DESTDIR set in the environment by Baserock.

It is entirely superfluous, since if make is asked to subtitute an undefined variable, it defaults to the empty string.

I can only think that the developer didn't know this fact, since it has existed as long as screen has supported DESTDIR, it's either that or the developer wanted you to have to run make DESTDIR="$DESTDIR" install.