| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
For the same reasons commit 7aa28456d ("Add dependency type for
Valgrind") removed linking with valgrind, pkgconfig shouldn't generate
"Requirements" for it, in general.
This solves dbus meson port question/issue from:
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/303#note_1444819
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
|
|
|
|
|
|
|
|
MachineChoice is a mesonlib object, not a compilers object, so it makes
no sense to import it from the latter simply because the latter imports
it too. This results in brittle module dependencies and everything
breaking when a refactor removes it from the latter.
... also it is a typing-only import so while we are fixing it to import
from the right place, we can also put it in a type-checking block.
|
|
|
|
|
|
|
|
according to commit https://github.com/wxFormBuilder/wxFormBuilder/commit/8a3d1697c819b8a8b41a136a865439b205997ae1
|
|
This is undefined behaviour, and seems to have caused test failures
when backporting Meson to an older toolchain in the Steam Runtime.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
We used the wrong spelling for both the object and the function. Link to
both, once in the description and once in the example code.
|
|
We want to talk about the kwargs to the custom_target() function, but
tried to link to custom_tgt instead, which is not a function. It is an
object, but this was the wrong reference method for a type.
We want the function anyway, so use that.
|
|
|
|
|
|
|
|
The end of the paragraph indicates that the options which support --foo
will be listed in the help text. The beginning of the paragraph seems to
suggest the same thing, except it doesn't distinguish between -Dfoo and
--foo style options.
The first mention is redundant and feels like the wrong part of the
paragraph to mention it anyway.
|
|
|
|
15 is the current snapshot version, 13 and 14 are released.
|
|
|
|
With the previous commit, we made this smartly detect when parentheses
are not needed. But the example was broken, because it doesn't follow
its own documented rules to use `[[#` syntax. Add the missing hash
character.
|
|
If we link to
```meson
[[#function]]('posarg')
```
then the ideal linkification would operate on "function" in the
formatted text:
```
function('posarg')
```
Instead, it operated on "function()" in the formatted text:
```
function()('posarg')
```
Fix this by detecting the next character after the reference, and
skipping the usual "automatically append the () for you" stage if it
already has that opening parenthesis.
|
|
The old implementation assumed a path is of Windows iff the second
character is a colon. However, that is not always true.
First, a colon can be included in a non-Windows path. For example, it is
totally fine to have a directory named ':' on Linux 5.17.0 tmpfs.
Second, a Windows path may start with \\ for UNC or extended length.
Use pathlib to handle all of these cases.
|
|
Regardless of which MachineChoice we base the platform on, we compare
its value to lowercased identifiers. So we need to lowercase the
targetplatform too... but we only did so sometimes.
This broke e.g. on "Win32", but only when *not* doing a cross build.
Fixes #10539
|
|
Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.
- Included permissions for the action. https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
[Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)
Signed-off-by: neilnaveen <42328488+neilnaveen@users.noreply.github.com>
|
|
1 (COLUMNS <= 60) by falling back to `_col`, relevant issue #10211
|
|
|
|
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.
|
|
|
|
add D generated files to order-only deps
|
|
If there isn't a preexisting dependency on python, append one. It's
almost assuredly needed, so just do the right thing out of the box.
|
|
Modeled similarly after the installations cache, but using the coredata
dependency cache because it has a nice mechanism for handling the cache
key.
|
|
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
|
|
In commit 3dcc7125833cae138987aa4535c88dbd4dbd960d 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
|
|
Agrees with Release Notes, Section 1.1, Table 3.
https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html
|
|
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.
|
|
It doesn't matter whether it is make or not, because make, too, supports
setting it via the env. This reduces the use of special cases in the
code.
|
|
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.
|
|
|
|
We will momentarily use this to implement typed_kwargs, but not for all
usage sites.
|
|
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.
|
