| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It returns `None | PackageDefinition`, not `PackageDefinition`
|
|
These aren't meant to be called externally. Additionally, they expect
some statefulness from the `resolve()` method, and by making them
protected we can more easily remove this statefulness.
|
|
Since they do not implement a default install dir like BuildTargets do.
Fixes: #12843
|
|
|
|
|
|
Followup to commit 5c479d7a13a518c18ccb4dc3b6bdd7bfc2a9bdb5.
In this case, PEP 668 was created to allow a thing that Debian wanted,
which is for `pip install foobar` to not break the system python. This
despite the fact that the system python is fine, unless you use sudo pip
which is discouraged for separate reasons, and it is in fact quite
natural to install additional packages to the user site-packages.
It isn't even the job of the operating system to decide whether the user
site-packages is broken, whether the operating system gets the answer
correct or not -- it is the job of the operating system to decide
whether the operating system is broken, and that can be solved by e.g.
enforcing a shebang policy for distribution-packaged software, which
distros like Fedora do, and mandating not only that python shebangs do
not contain `/usr/bin/env`, but that they *do* contain -s.
Anyway, this entire kerfuffle is mostly just a bit of pointless
interactive churn, but it bites pretty hard for our use case, which is a
container image, so instead of failing to run because of theoretical
conflicts with the base system (we specifically need base system
integration...) we fail to run because 5 minutes into pulling homebrew
updates at the very beginning, pip refuses point-blank to work. I
especially do not know why it is the job of the operating system to
throw errors intended for interactive users at people designing system
integration containers who cannot "break" the system python anyway as it
is thrown away after every use.
Fix this by doing what homebrew should have done from the beginning, and
opting containers out of this questionable feature entirely.
|
|
This code cleverly tried to use a fancy new pathlib.Path method to get
the os.path.commonpath of two paths and check whether one is inside the
other. It failed pretty badly, because of a hidden secret of pathlib: it
is designed to throw random exceptions at all times (except when
building os.PathLike interfaces) instead of performing useful work.
Return to `os.path`.
In particular, before this change, we wanted to check if files are NOT
in a subpath of `preserve_path_from`, and raise a meson "ERROR: xxx" in
such a case. However, the code to check for it would raise a python
ValueError if that was the case, so we never got to the properly
formatted error.
|
|
Since we don't get a location for these errors, we can at least tell you
which targets you happen to be mixing together that produce this
problem.
Ran into while trying to debug a target mixing bug.
|
|
0e7fb07 introduced a subtile bug in the Python module.
If a python version is found, but is missing a required module,
it is added to the list of python installations, but the
`run_bytecompile` attribute for that version was not initialized.
Therefore, if any other python version added something to install, it
was raising a KeyError when trying to read the `run_bytecompile`
attribute for the python version with missing module.
|
|
Using scan-build gives the following warning:
"Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated."
This commit fixes this issue by adding the setup keyword to the meson command.
|
|
They accept list as documented
|
|
This allows using "--undefine __meson_verbose" to disable the verbose
mode. This is useful when running rpmbuild in an interactive terminal
and you don't want to be flooded with compilation outputs.
We also add --quiet to the meson install macro if __meson_verbose is
undefined to reduce the output generated by meson install.
The default output stays the same, the output is only affected if
__meson_verbose is explicitly undefined.
|
|
The .lcovrc file can contain several directives for genhtml, mostly
pertaining the visualisation of the generated HTML report. Passing the
config file to genhtml allows the user to customize their report.
Fixes #12863
|
|
The following workflows have been updated so that they are
triggered when the any of the test harnesses are updated:
macos,
os-comp,
msys2
Previously only changes to `run_unittests.py` caused these
workflows to be executed.
|
|
On Debian systems the cython compiler binary is installed as
`cython3`. The current logic for detecting whether to run the Cython
unit tests instead checks for `cython` or the value of the `CYTHON`
environment variable, which leads to cases where the underlying Meson
can correctly compile Cython code but the test harness excludes these
tests from execution because it cannot find `cython3`.
This commit makes the test harness use the same detection method as
Meson itself. It also takes the opportunity to refactor some existing
code which does the same job for Objective C and Objective C++ tests
to avoid repetition.
|
|
A config-tool method has been supported since c02593f and it says so
just a few lines below the outdated statement.
|
|
Special notes:
- _nvcc_arch_flags is always called with exact arguments, no need for
default values
- min_driver_version has its args annotation loosened because it has to
fit the constraints of the module interface?
|
|
The min_driver_version function has an extensive, informative custom
error message, so leave that in place.
The other two functions didn't have much information there, and it's
fairly evident that the cuda compiler itself is the best thing to have
here. Moreover, there was some fairly gnarly code to validate the
allowed values, which we can greatly simplify by uplifting the
typechecking parts to the dedicated decorators that are both really good
at it, and have nicely formatted error messages complete with reference
to the problematic functions.
|
|
It is pretty trivial and more confusing when standalone, especially the
use of a sentinel "unknown" string as a standin for "this isn't one of
the allowed object types". Much easier to directly raise an error in the
fallthrough/else.
|
|
It is only ever invoked once. It has a statically known signature based
on how it's used, so there's no good reason to allow it to accept any
defaults -- and defaulting to None messes with type safety.
Saturate is always given, so don't claim it is only sometimes.
|
|
This officially only ever accepted string or array of strings.
|
|
IfClauseNode is only ever initialized in such a way that this attribute
is immediately set to something valid. And attempting to access its
value when the value is None would be a pretty broken error anyway. The
assignment served no purpose, but did perform a frivolous runtime op in
addition to angering mypy's checks for implicit None.
|
|
An oddity: sys.stdout is statically defined as type TextIO instead of
TextIOWrapper, and thus doesn't have a .reconfigure method. This is
because they expect people to override sys.stdout with other objects,
which we do not do. Instead, assume it is always correct.
There are two final errors due to metaprogramming:
```
mesonbuild/mesonmain.py:196:13: error: Returning Any from function declared to return "int" [no-any-return]
mesonbuild/mesonmain.py:225:9: error: Returning Any from function declared to return "int" [no-any-return]
```
|
|
The add_arguments function is always called with a formatter in
mesonmain.py, and if it were not, then it would be incorrect when
calling argparse itself -- because formatter_class cannot be None, and
defaults to its own builtin one. This violates None-safety.
|
|
Instead of returning Optional, a state that is only possible during
`__init__` and which prevents mypy from knowing what it is safe to
assume it will get.
|
|
The standard library accepts None defaults for some kwargs and we should
too.
|
|
It's an improper object model, but was used to signal to a subclass that
self.traceparser did not exist. However, since it is always initialized
from self.cmakebin, we can just check that instead.
|
|
|
|
|
|
Since commit abc7e6af01714206100a752898c325282436501f it is not possible
for this set of methods to return None, which was an odd thing to return
to begin with. Cease to annotate it as such.
|
|
It can be a list or a single dependency, but the same logic happens
either way. Instead of manually expanding the logic for both cases, just
convert it to a list as needed.
|
|
This allow to generate ui and moc under subdirectories,
as this is allowed with generic generators.
|
|
Oops.
Fixes: 7b7d2e060b447de9c2642848847370a58711ac1c
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
Raise MesonException if a postconf script fails to let the user know
about the failure.
|
|
|
|
The type of quoting was changed in 522392e to one that is suitable for
use with cmd.exe on Windows. However, the documentation states that the
type of quoting in MESONINTROSPECT is compatible with shlex.split() and
elsewhere in the code, the same variable is still quoted with
shlex.quote(). As mostly identified in #12148, there are a few choices:
1. Use shlex.quote() consistently and support Python but not cmd.exe.
2. Use join_args and support cmd.exe but not Python.
3. Use join_args and support splitting through the mesonbuild Python library.
This commit implements the first option and reverts part of 522392e.
Regression testing is implemented in #12115.
Fixes #12148
|
|
We need to load various environment variables from /etc/profile. We
cannot unconditionally load it, because opensuse sources env_vars and
their /etc/profile has a fatal bug in it that causes it to return
nonzero and abort under `set -e` (which is *amazing* as a thing to have
in /etc/profile specifically -- just saying).
Alas, even /etc/profile.env is not enough since Java support depends on
profile.d logic. Re-conditionalize this check to only be added to
env_vars.sh for the image named "gentoo".
|
|
It is properly detected as unavailable, ever since commit
d1b783fc6923efa1a891d6d3a717e4e5ad15de21
|
|
On the openSUSE builder, we got a horrifying CI failure like:
```
FAILED: asubdir/subdir-prog.p/main.cpp.o
c++ -Iasubdir/subdir-prog.p -Iasubdir '-I../test cases/frameworks/5 protocol buffers/asubdir' -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++14 -O0 -g -DPROTOBUF_USE_DLLS -DNOMINMAX -MD -MQ asubdir/subdir-prog.p/main.cpp.o -MF asubdir/subdir-prog.p/main.cpp.o.d -o asubdir/subdir-prog.p/main.cpp.o -c '../test cases/frameworks/5 protocol buffers/asubdir/main.cpp'
In file included from /usr/include/google/protobuf/stubs/common.h:20,
from /usr/include/google/protobuf/io/coded_stream.h:107,
from asubdir/subdir-prog.p/defs.pb.h:26,
from ../test cases/frameworks/5 protocol buffers/asubdir/main.cpp:1:
/usr/include/absl/strings/string_view.h:52:26: error: ‘string_view’ in namespace ‘std’ does not name a type
52 | using string_view = std::string_view;
| ^~~~~~~~~~~
[...]
```
This turns out to be because of a *huge* mess with abseil-cpp and protobuf. We're
still trying to handle it in Gentoo, even (see bgo#912819) and https://github.com/gentoo/gentoo/pull/32281.
In summary, abseil-cpp started to require C++17 (unless built with a special option
which causes ABI problems). Let's switch the protobuf test case to use C++17
accordingly. There's some precedence for Just Doing This, like in cb54f0d707e5673eb1d8aaafae59a6d5fde25e18
recently for Boost, and 792a84199b8829c923968e8816a27e021647d146 previously for
protobuf itself.
Bug: https://bugs.gentoo.org/912819
See also: https://github.com/gentoo/gentoo/pull/32281
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
FAILED unittests/linuxliketests.py::LinuxlikeTests::test_install_strip - FileNotFoundError: [Errno 2] No such file or directory: 'file'
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
We may want to consider our own binpkg cache for future to speed things up,
in addition to the ones provided by Gentoo's own binhost.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
This will add highlighting when viewing on GitHub.
|
|
This adds bash completion to everything that I could think of except for
the rewriter.
|
|
This was implemented in dc51740e2cdee171ac6ebc7ed261e5c08730c9a9,
but was not added to the documentation or marked as a new feature.
|
|
Fixes https://github.com/mesonbuild/meson/issues/12092
|
|
This reverts commit 718c86a7d577e6474ff325957248724d9b786174.
We can't always use git to apply patches because they might actually
apply to a git submodule inside a git subproject, and git will not be
able to apply the patch in that case.
|
|
|
|
In 89146e84c9eab649d3847af101d61047cac45765, a heuristic was introduced where
if libLLVMSupport is available as a static library, LLVM itself is assumed
to be availble as a static library as a whole.
This is unfortunately not the case at least on Gentoo and Arch Linux, where
a subsequent llvm-config call yields:
```
$ /usr/lib/llvm/17/bin/llvm-config --libfiles --link-static
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMTargetParser.a
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMBinaryFormat.a
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMBitstreamReader.a
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMRemarks.a
[...]
```
On Gentoo, where LLVM's static libraries are not included, we still have:
```
$ equery f llvm:17 | grep -i lib64/.*.a$
/usr/lib/llvm/17/lib64/libLLVMDemangle.a
/usr/lib/llvm/17/lib64/libLLVMSupport.a
/usr/lib/llvm/17/lib64/libLLVMTableGen.a
/usr/lib/llvm/17/lib64/libLLVMTestingAnnotations.a
/usr/lib/llvm/17/lib64/libLLVMTestingSupport.a
/usr/lib/llvm/17/lib64/libllvm_gtest.a
/usr/lib/llvm/17/lib64/libllvm_gtest_main.a
```
Therefore, testing for libLLVMSupport is insufficient. We now try libLLVMCore
instead, as that appears to only be installed when LLVM truly has static libraries
available. libLLVMCore is handled as a LLVM component which gives us some guarantee
this is supposed to be happening and not a fluke.
(Specifically, LLVM's llvm/lib/Support/CMakeLists.txt pays 0 attention to
-DLLVM_BUILD_LLVM_DYLIB and -DLLVM_LINK_LLVM_DYLIB, and is hence only affected
by -DBUILD_SHARED_LIBS, which LLVM upstream say is only to be used for development.
Therefore, with -DBUILD_SHARED_LIBS=OFF (as is recommended/the default) and
-DLLVM_BUILD_LLVM_DYLIB=ON, you will get a static libLLVMSupport, without it
indicating anything about the rest of your configuration.)
Closes: https://github.com/mesonbuild/meson/issues/12323
Fixes: 89146e84c9eab649d3847af101d61047cac45765
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
