We have to handle this, because Windows needs to link to the implib of
the executable (???) in order to create a shared module. This is
explicitly checked for and handled in the backend, and creating a build
target with `link_with: some_exe` still works, even. But updating
declare_dependency to typed_kwargs neglected to take that into account,
so creating a convenience interface for those same arguments failed.
In PR 10263, we didn't account for that we may have initialize the Visual
Studio-like compiler two times, once for a C compiler and once for the
C++ compiler, so we end up with Meson breaking on Visual Studio 2013
or earlier, such as when building GLib.
Fix this by setting up the always_args member of
the VisualStudioLikeCompiler instance during __init__() as needed, so that
we avoid falling into modifying shared objects.
In commit 3dcc712583 we moved to
typed_pos_args. In the process, we deleted some code to specifically
raise an error if you use custom_target or generator outputs, instead
leaving it out of the typed pos args.
However, that support was specifically supposed to be there. It was only
an error in part of an if statement for handling old versions of
glib-compile-resources. The specific error it calls out is that we need
to manually parse the depfile at configure time, due to an external bug;
obviously this is impossible if the gresource is only created at build
time.
Reinstate the original error message check, and allow built outputs to
be used as compile_resources() inputs.
Fixes#10367
The check for if the project supports the -j flag was needlessly
complex. We support two types of project:
- waf, always supports -j
- make, if GNU, supports -j
We never checked waf, and the make check assumed that the entire
command, rather than just the last component, was "make". It also
neglects "gmake".
Since any possible build command *may* support -j, always run the
--version check. Detect either build command in the output.
The unit test was racy but surprisingly never failed on CI. The reason
is we need to ensure ninja build somelib.so before running `make` into
the external project.
Dlang uses both integer version "levels" and arbitrary string
identifiers, and we support both, but don't mention it in the docs.
Also update a test case to pass one via declare_dependency. We already
test this kwarg for build_target.
The type information is clearly wrong as it disagrees with the
description w.r.t. generated headers.
We also rely on it accepting custom targets for the obvious reason that
we accept it in a build target too! In fact, we rely on this in the
testsuite too.
We can use this lots of places, and it's always the same kwarg. There
doesn't seem to be a point in naming it badly, then evolving it to the
standard name in the one place it is currently used. This made it not
shareable.
Given a kwarg value that is itself a dict/list, we would only check if
the since_values was present within that container. If the since_values
is itself the dict or list type, then we aren't looking for recursive
structures, we just want to know when the function began to accept that
type.
This is relevant in cases where a function accepted a dict, and at one
point began accepting a list (of strings in the form 'key=value'), or
vice versa.
The check for whether or not a file is allowed to be accessed from a
subproject fails if the subproject is accessed via a symlink. Use the
absolute path of the subproject without resolving symlinks to fix the
check.
Extend unit test 106 to check for this in the future.
At several points in the code base, f-strings are not correctly expanded
due to missing 'f' string prefix. This fixes all the occurrences I could
find.
- Remove duplicated code in mdevenv.py
- Change the limit to 1024 instead of 2048 which is what has been
tested.
- Skip shortening if it is already short enough.
- Skip shortening with wine >= 6.4 which does not seems to have that
limitation any more.
- Downgrade exception to warning in the case WINEPATH cannot be
shortened under 1024 chars, it is possible that it will still work.
Merging snippets happens in arbitrary order -- whatever filesystem
globbing results in. This didn't matter too much when we ran it once at
release time and checked the resulting release notes into git. However,
now that we generate a temporary version of the release notes for
development versions, the order of the results will periodically change.
Sort the files before processing them in order to guarantee that
whatever order they are in, they stay that way.
As a side effect, it's now technically possible to guarantee an ordering
by judicious use of snippets naming.
Regression in commit 7c757dff71.
SubprojectHolder is no longer an ObjectHolder and says so via a TODO:
this means that we have to fiddle with held_object. Yay.
The `add_deps` function did not behave correctly when a specified
dependency is not an instance of `dependencies.Dependency`.
Reorder the logic flow to perform this validation first.
Fixes#10468
When need to catch exceptions just like we do in coredata.load() to
print proper error message instead of backtrace when user mix meson
versions.
This happens frequently when user has a newer version of meson installed
in their HOME and then "sudo meson install" uses the system version of
meson.
If we increment the build revision and re-release a wrap, it's a bugfix
of an old version, so we can simply not bother to list it in the table.
Just list the latest and greatest wrap for each tagged release.
The rest are obviously still available if you look up the relevant tag
manually on github, but they aren't very interesting to show here.
When a subproject is disabled on the initial configuration we should not
add it into self.coredata.initialized_subprojects because that will
prevent calling self.coredata.init_builtins() on a reconfigure if the
subproject gets enabled.
Fixes: #10225.
Instead of asking the ExtractedObjects, but with a hook back into the backend,
use the existing function in the backend itself. This fixes using the
extract_objects(...) of a generated source file in a custom_target.
It should also fix recursive extract_all_objects with the Xcode backend.
Fixes: #10394
A single target could be picked for unity build, and in that case
extract_objects() should not be allowed.
Likewise for the opposite case, where extract_objects() should be allowed
if unity build is disabled for a single target. A test that covers that
case is added later.
'meson-test-prereq' now depends on any targets that were formerly added
directly to 'all'. Behavior is not changed -- the all target still
depends on this other meta-rule, and thus indirectly depends on all
targets it used to depend on.
It is now possible to build just the targets needed for the testsuite
and then e.g. run `meson test --no-rebuild`.
We only want to scan stdout for these strings, and particularly, if we
allow `-d explain` to be mingled into stdout, then buffering issues
across OSes can lead to inaccurate results.
Xavier Claessens
Eli Schwartz
CLanguagePurist
Chun-wei Fan
Jussi Pakkanen
Olexa Bilaniuk
Staz M
Hemmo Nieminen
Michael Mera
fxxf
Seungha Yang
Paolo Bonzini
ff
Stepan Nassyr