maint.mk: RELEASE leaking into VERSION

[Simon Josefsson]

Hi,

I ran into this problem today and I'm surprised we haven't seen reports
about it long time ago.  The problem is that if you have the RELEASE
environment variable set when building a package that uses gnulib, the
content of that environment variable leaks into the VERSION makefile
variable, which is often used during builds via make's $(VERSION).

You can reproduce this using, e.g., cppi-1.18 released in 2013:

wget https://ftp.gnu.org/gnu/cppi/cppi-1.18.tar.xz
tar xfz cppi-1.18.tar.xz
cd cppi-1.18
./configure
make check # passes
env RELEASE=foo make check # fails

For me the build failure only occured during Debian CI/CD builds, which
set the RELEASE environment variable to the Debian distribution used
(e.g., "unstable").  Understanding what was happening took some time...

Maybe few people have a RELEASE environment variable, and maybe few
packages depend on the make $(VERSION) variable being correct, which
would explain lack of earlier reports.

The reason all this happens is this code in top/maint.mk:

# If RELEASE_TYPE is undefined, but RELEASE is, use its second word.
# But overwrite VERSION.
ifdef RELEASE
  VERSION := $(word 1, $(RELEASE))
  RELEASE_TYPE ?= $(word 2, $(RELEASE))
endif

This is only ever used during the release process for maintainers,
e.g. make release RELEASE='1.2 stable'.

Can someone think of a simple but backwards compatible fix here?  Is it
possible to only apply the VERSION/RELEASE_TYPE fix when rules related
to 'make release' is invoked?

One of the problem with this code is that it is executed top-level,
which applies to all invocations of 'make' for anyone building projects
using gnulib.  Maybe there are other snippets like this we don't
necessarily want to be executed for each and every user 'make' command.

When you know about this problem, it is easy to work around, for
example: sed -i -e 's,ifdef RELEASE,ifdef GL_RELEASE,' maint.mk

/Simon

signature.asc
Description: PGP signature