Simplify version extraction from a file

Providing some way to replace the following pattern would be welcome:

project('foo', 'c',
  version: run_command(
    find_program('python'), '-c', 'import sys;print(open(sys.argv[1]).read())', files('VERSION')
  ).stdout().strip(),
)

Drawbacks with this current approach:

• we can’t move the run_command() in a variable before project(), which likely implies this is currently a nasty hack where we’re probably not supposed to do that
• some system may have python3 and not python, and the other way around is also true
• using run_command(find_program('cat'), ...) instead of python would be fatal on Windows
• having a dedicated Python script is quite an overhead, and doesn’t address the external subprocess hack to just read a file

Rationale

So the current scenario we’re in is the following: we are managing our releases through Github, where making a release is basically simply pushing a tag. So we have the following primitive make-release.sh script:

#!/bin/sh

#
# Release process:
# 1. on a clean git state, run this script with the new version as argument
# 2. check the last commit and tag
# 3. git push && git push --tags
#

set -eu

if [ $# -ne 1 ]; then
	echo "Usage $0 <major.minor.micro>"
	exit 1
fi

cd "$(dirname $0)"

if ! git diff-index --quiet HEAD; then
	echo "Git index is not clean"
	exit 1
fi

set -x
VERSION="$1"
echo "$VERSION" > VERSION
git add VERSION
git commit -m "Release $VERSION"
git tag "v$VERSION"

The VERSION file is basically the channel of communication between this script and meson.build

Alternative considered

• hot-patching meson.build within the release script, but it’s not exactly cleaner to say the least
• using dist scripts with meson; unfortunately we’re running git commands at an unfortunate timing, and it involves quite some logistic
• requesting in the release process to patch the meson.build with the new version, and then extracting the version with the meson introspection with tools like jq in the release script; this creates an annoying dependency to jq, and it also makes the release process much more clumsy than just running a script

How it could look like

Here are a two usage suggestions that would simplify and make this workflow much more reliable, which I believe are not very intrusive:

• project('foo', 'c', version: files('VERSION')) (it’s part of the source files after all)
• project('foo', 'c', version: meson.get_file_content('VERSION'))

[ldrumm]

Adopting something like cmake’s FILE(READ... is less magical and is much more flexible for other uses. I can imagine a fair few scenarios where reading the contents of a file might be useful in meson for configuration and trivially enables the behaviour needed by Mesa

I’d definitely be happy to see the following (from the example above) for my own purposes

project('foo', 'c', version: meson.get_file_content('VERSION')).strip())

cmake’s interfaces for files are pretty unpalatable to work with, but I think this is an excellent way to solve the problem in a general way.

@jpakkane I’d be happy to provide a patch for the above. Let me know if that’s the route you want to take and I’ll push a PR

[eli-schwartz]

“force a reconfigure” means add a ninja rule for running the reconfigure, which in addition to depending on meson.build etc. also depends on that file.

deleting a file that the build rule depends on already forces reconfigure and presumably generates a new build.ninja without that file dependency. Adding a file would cause the file to be newer than build.ninja, forcing reconfigure, but might have the problem of being a fatal error if you do not have the file and cannot create it as a prerequisite…