| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 which is fortunately tested before deployment, so
instead of failing to deploy because of theoretical conflicts with the
base system (we specifically need base system integration...) we fail to
deploy because 5 minutes into pulling apt 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 baking "appliance" containers who cannot "break" the
system python anyway.
Fix this by doing what Debian and Ubuntu should both have done from the
beginning, and opting containers out of this questionable feature
entirely.
Note that CI images may still not actually complete their build/test
cycle and be updated, because e.g. LLVM 16 issues tracked by #11642 or
glib ASAN issues tracked by #11754.
|
|
This issue was encounetered while working on a contribution to nixpkgs.
Nix allows the store to be installed on a separate, case-sensitive APFS
volume. When the store is on a case-sensitive volume, these tests fail
because they try to use `foundation` instead of `Foundation`.
|
|
|
|
fix package ordering to so Q* and r* packages are in alphabetical order.
|
|
|
|
This can be the longest part of the entire test process, often with no
benefit because we already know the environment is sane. So, let's have
an option save some time.
|
|
Allow the use of wildcards (e.g. *) to match test names in `meson test`.
Raise an error is given test name does not match any test.
Optimize the search by looping through the list of tests only once.
|
|
- Do not hardcode terminal width of 100 chars, that breaks rendering on
smaller terminal. It already uses current console width by default.
- Disable progress bar when downloading from msubprojects because it
fetches multiple wraps in parallel.
- Scale unit when downloading e.g. MB/s.
- Do not display rate when it's not a download.
- Do not display time elapsed to simplify the rendering.
|
|
We silently dropped all integer values to install_mode since the
original implementation of doing this in KwargInfo, in commit
596c8d4af50d0e5a25ee0ee1e177e46b6c7ad22e.
This happened because install_mode is supposed to convert False
(exactly) to None, and otherwise pass all arguments in place. But a
generator is homogeneous and attempting to do this correctly produced a
mypy error that FileMode arguments were allowed to be ints -- well of
course they are -- so that resulted in the convertor... treating ints
like False instead, to make mypy happy.
Fixes #11538
|
|
This convertor was initially implemented doing all the things the TODO
says it doesn't yet do. The freestanding interpreter function is what
doesn't do this.
|
|
This option can never have a value of None. There are only two sources
of values at all:
- the class instance initializer when defining BUILTIN_CORE_OPTIONS
- user-provided command-line or machine file values etc. which can only
be meson types
We know we don't construct the Option instance with None, and users
cannot pass a None anywhere since that's not a meson type. The only
reason this was ever checked for was as an artifact during the initial
implementation of the option in commit 8651d55c6a317de37dcaa9965157151095a88292.
At the time, a review comment was made that `-Dinstall_umask=none` was a
bad UX and "preserve" should be used instead. Before that, this option
type accepted `None` (in the BUILTIN_CORE_OPTIONS initializer) and
`'none'` (provided by users) which is odd and should have consistently
been the latter. Then inside set_value, it checked for the magic
initializer value and converted it to the real value.
After review comments and a force-push, the patch ended up using `None`
in the initializer, and `'preserve'` everywhere else, and still handling
both in set_value and converting both to a proper string.
In the very next commit in the patch series, the initializer was
migrated to use an actual umask of 022, and now `None` was entirely
impossible to get anywhere at all. But the wart of checking for it was
never removed. Remove it at long last.
|
|
I would like to use the same pattern rule as github actions uses:
'[0-9]+.[0-9]+'
But azure pipelines doesn't document what the syntax here is, and it
scares me that perhaps the reason we didn't already do this is because
it doesn't work at all.
|
|
It is not very clear from the documentation that the dependencies in the
resource file are added as default dependencies to the target.
|
|
This has never been undocumented and there's no obvious value to having
it or using it. We're not even sure anyone ever has used it.
Closes #6061
|
|
16.0.4 didn't fix the LLVM breakage.
|
|
|
|
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.
|
|
The concept of merge_file intrinsically requires some GNU-specific
functionality, so let's emit a useful error message during
configuration, when we don't have that.
The relevant GNU gettext versions date back to around 2015 so *probably*
anyone has that too, but we may as well verify that while we are here.
|
|
There are a number of implementations for msgfmt, supporting various
options. The simplest, and most common, use case is to compile .po files
into .mo files, and this should be able to work on gettext
implementations other than the GNU one.
The problem is that we were passing some pretty portable arguments in an
unportable manner. The `-o` option-argument and its associated argument
came after the input file operand, which violates the POSIX Utility
Syntax Guidelines, and happens to not be supported by Solaris gettext.
The GNU gettext doesn't care; GNU invented GNU argument permutation.
Switch the order around so that our use respects the POSIX style.
|
|
- add `extra_paths` to intro-tests.json to know paths needed to run a
test on Windows;
- add `depends` to alias targets in intro-targets.json to know what
targets does an alias point to;
- add `depends` to intro-dependencies.json to know libraries linked with
an internal dependency;
- renamed `deps` to `dependencies` in `intro-dependencies.json` for more
uniformity.
|
|
Fixes #1141
|
|
|
|
|
|
It is a common mistake that is hard to find because Meson silently
ignore unknown sections. Better have an explicit error message.
|
|
* DubDependency._check_dub returns the version
* check for compatible Dub version
Dub versions starting at 1.32 have a new cache structure
into which Meson doesn't know where to find compatible artifacts
* skipping D tests involving Dub
* refactor _check_dub
makes mypy happier
* make linters happy
* localize some logic
|
|
|
|
Don't spew debug-level info. Log the actual command line run.
|
|
It's particularly inscrutable if you do not know where DLLs weren't
found because you don't know what the PATH was in the child process.
|
|
|
|
Fixes #1709
|
|
sanity check.
|
|
Fixes #11047
|
|
Also check that they are available in meson.build.
Closes #11772
|
|
Users now have the *option* to run the documentation build and use
`meson install` to install man pages.
|
|
Reorder meson targets to handle those all at the end, and exit early if
HTML documentation is disabled. This makes it possible to build just the
manpage, without hotdoc installed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CPython adds a hard to avoid hardcoded link flag to look for a debug
libpython. This results in a very puzzling error, so emit a warning
with a clear message. Note that pybind11 has a workaround for this,
which undefines `_DEBUG`. So users who use only pybind11 can use
non-release buildtypes, but they won't get debug symbols on Windows
unless they have a debug build.
|
|
|
|
[skip actions]
|
|
[skip actions]
|
|
This matches the tests for Python extensions.
Also include some other cleanups to these `meson.build` files:
Adding `python_dep` is no longer needed, this is automatic now.
Use a single line for `import('python').find_installation()`,
because the result of `import('python')` by itself is not used
for anything.
|
|
If the dependency permits it, we can just do a PATH search instead of
mandating that it be listed in the cross file. This is useful for the
limited case where a specific dependency is known to be compatible with
any machine choice.
Mark the pybind11 dependency as supporting this. It's a valid choice
because pybind11 is a header-only C++ library.
|
|
In #11761 it turned out that we failed to correctly handle all
compiler.sizeof API changes in an old commit, breaking use of the
module. And mypy could have caught this for us, except that the module
is neither typed nor checked in CI. Partially solve this by adding lots
of type annotations, greatly reducing the number of mypy errors in this
file from 35 down to 12.
|
|
This doesn't accept a dict, only an actual ConfigurationData object. Due
to the way we poke at it, a dict can sort of work anyway, but might not
if the internal layout isn't exactly correct. This is evidenced by the
way we make the dict values be hard-to-read tuples containing emptiness,
because that's how ConfigurationData objects handle descriptions.
Simplify and make the seed dictionary readable, then actually convert it
into a real ConfigurationData. Bonus: this now passes type checking.
|
|
It's shorter and more descriptive. Although we always enforce the same
rules either way, a unified decorator is one less line of code for each
location, and also tells you how many "too few" arguments you *did*
pass.
|
