an int only accepts operations on other ints, just like other primitive
types only accept operations on values of the same type.
But due to using isinstance in baseobjects "operator_call", an int
primitive allowed operations on a bool, even though reversing the
operator and having a bool perform operations on an int, would fail with
a type error.
Really, we should fail with a type error in both directions. But for
stability reasons, make this a loud warning and break --fatal-meson-warnings
builds.
This is useful for totally terrible stuff that we really dislike, but
for some reason we are afraid to just use `mlog.deprecation()` and
unconditionally tell people so.
Apparently this is because it is totally absolutely vital that, when
telling people something is so broken they should never ever ever use it
no matter what, ever... we can't actually tell them that unless they
bump the minimum version of Meson, because that's our standard way of
introducing a **version number** to tell them when we first started
warning about this.
Sigh. We really want to warn people if they are doing totally broken
stuff no matter what version of Meson they support, because it's not
like fixing the thing that never worked is going to suddenly break old
versions of meson.
So. Here's some new functionality that always warns you, but also tells
you when we started warning.
The version output scraping for identifying strings checked for "IFORT"
in parentheses after the executable name, which is probably a mistake by
Intel. Current versions of ifx have "IFX" in parentheses there.
Detect both.
Fixes#11873
When a project targets a dev version of Meson (e.g. 1.1.99) for
experimenting, this allows to use:
project(..., meson_version: '>=1.2.0')
It avoids getting warnings when using FeatureNew for features introduced
in 1.2.0.
Specifically, when those files can be created by a build rule with one
version of meson.build, and created as e.g. a shared_library alias
symlink in another version of meson.build, the cleandead command will
delete important files just because they don't happen to be created by
ninja itself.
Work around this by making a dummy rule that exists solely to insert the
files into the build graph to trick ninja into not deleting them.
Closes#11861
- Include BaseNode position in hash methods, integer is the most
straightforward way of differentiating nodes.
- Exclude non hashable fields from hash method.
- Avoid using default values in BaseNode that way subclasses can have
fields wihtout default value without repeating init=False.
- Nodes that does not add fields does not need `@dataclass`.
- Make all node types hashable because they can be used for feature_key
in FeatureCheckBase.use().
- Remove unused type annotations
This is a pretty common pattern in python (the standard library uses it
a ton): A class is created, with a single private instance in the
module, and then it's methods are exposed as public API. This removes
the need for the global statement, and is generally a little easier to
reason about thanks to encapsulation.
We actually do not and should not care about wrap-mode at all for this.
We want to cache dependency lookups whenever humanly possible, but only
use them in cases where we would anyways be using them -- which in
particular means if we said to force a subproject fallback for this dep,
we want to bypass the cache.
Currently, we handle this by always looking up the cache for all
dependencies, but clearing the cache at startup if a reconfigure means
we are changing our resolution strategy. This is bad -- we might have
many dependencies that are worth caching, and only one dependency that
should stop being cached and use a subproject instead.
The simple solution is to handle the forcefallback case when doing a
cache lookup, and not do a cache lookup at all. Now we don't have to
nuke the entire cache. In fact, if a future reconfigure changes the
forcefallback state back to not being forced, we can reuse the original
cached dependency, which is still there.
Closes#11828
ninja's configured command for regenerating a build directory on any
action that *requires* reconfiguring, specifies the source and build
directories as they were known during initial project generation. This
means that if the build directory is no longer the *same* build
directory, we will regenerate... the original location, rather than the
location we want.
After that, ninja notices that build.ninja is still out of date, so it
goes and reconfigures again. And again. And again.
This is probably broken intentions, but endless reconfigure loops are a
kind of evil beyond all evils. There are no valid options here
whatsoever other than:
- doing what the user actually meant
- spawning a clear error message describing why meson refuses to work,
then exiting with a fatal error
But it turns out that it's actually pretty easy to do what the user
actually meant, and reconfigure the current build directory instead of
the original one. This permanently breaks the link between the two.
Fixes#6131
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
596c8d4af5.
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 8651d55c6a.
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.
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.
Xavier Claessens