In a3679a64e (programs: favor version numbers with dots, 2025-01-03) we
have changed the regex used to extract version numbers to favor dotted
versions. It was reported though that the regex doesn't match major
version numbers that start with multiple digits correctly. Fix this.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
When using `find_program('perl')` we misdetect its version number:
Program perl found: YES 40 40 (/usr/bin/perl)
This is caused by Perl outputting the version information in a somewhat
weird format:
$ perl --version
This is perl 5, version 40, subversion 0 (v5.40.0) built for x86_64-linux-thread-multi
...
The problem here is that our version number detection picks the first
match of at one digit followed by at least one more digit and/or dot.
Consequently, as "40" matches that regular expression, we'd return its
value as the version number.
Naturally, the version number detection we perform is best-effort, only,
as there is no standardized format used by all programs. That being
said, we can do better here by first trying to match a dotted version
number so that we'd match the "5.40.0" string, not the "40". And given
that most projects use dotted version numbers this should be a strict
improvement in cases where we have multiple digits in-text. The old
behaviour continues to be used as a fallback though in case we weren't
able to match anything to not regress functionality.
The new regex also fixes another case: when the version information ends
with a trailing dot, like "foo version 1.2.3.", then we'd also have
matched that trailing dot. This can be for example the case when version
numbers end with ".rc1" or something similar. While we'd ideally include
such suffixes into the detected version, that issue is left for another
day.
Add a couple of tests.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
On Windows, if the native file contains a path without the
extension, the executable may be found, but custom target would
fail because that path does not exist.
When we're using the output of configure_file() with
override_find_program(), we weren't storing the version anywhere, so
get_version() was trying to run the script during setup.
This is usually fine, except in cases where the configure_file()
script actually has to import a library built as part of the project,
and fails to run.
For built executables, we simply use the project version, and we
now do the same here too.
These errors can make reading comments and documentation
unnecessarily confusing for users and contributors who
do not speak English as their first language.
When trying to get the version of a program, meson was previously
hardcoded to run the binary with `--version`. This does work with the
vast majority of programs, but there are a few outliers (e.g. ffmpeg)
which have an unusual argument for printing out the version. Support
these programs by introducing a version_argument kwarg in find_program
which allows users to override `--version` with whatever the custom
argument for printing the version may be for the program.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
Currently you can only use one of qt4, qt5, qt6 in a single project
when using a machine file because the config-tool lookup for qt only
looks at `qmake` in the machine files, instead of looking up the
binary names directly.
Allow specifying `qmake` `qmake4` `qmake5` and `qmake6`.
This is necessary for gstreamer, which can build separate qt5 and qt6
plugins that are distributed as static libraries, so the user can pick
which one to use.
It is only used by Environment.get_exe_wrapper() and every callers were
handling None already. Type annotation was wrong, it already could
return None for the case an exe wrapper is needed but none is provided.
This also cleans up a couple of internal callers of the internal impl
version that don't set the `check` argument, and therefore trigger a
warning about not setting the check argument.
This will always be wrong, because when a directory component is
provided we need to match an exact filename on a manual search path, for
example find_program with dirs: or the current meson.build subdir.
If we ever get this far, shutil.which will do the same "is there a
dirname, if so just check whether the filename exists relative to
cwd"... except that the documented meson lookup path is that we check
relative to meson.build subdir, not relative to the cwd, and the cwd
could be anything, but is probably the root sourcedir.
Since internally, meson does not actually os.chdir into the sourcedir,
it could be absolutely anything at all, though.
...
The actual returned name for shutil.which(name) given a literal pathname
with a directory component is "return name" without adding the absolute
path, which means that this is double-broken. Not only does it find
things we didn't expect, the resulting ExternalProgram object doesn't
have the correct path to the program, so it will report "found" and then
fail to actually run when the current directory is changed, for example
by ninja -C.
Fixes#9262
Dependencies is already a large and complicated package without adding
programs to the list. This also allows us to untangle a bit of spaghetti
that we have.
Patrick Steinhardt