| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Which is useful as we move the validation out of the the
EnvironmentVariablesObject
|
|
|
|
|
|
|
|
There is a unit test using it and now fails because the warning about
unknown kwarg became fatal.
|
|
|
|
|
|
Fixes #9191
|
|
This seems like an oversight, that we'd replace ppc with ppc64 on AIX
for the cpu_family, but not for the specific cpu.
|
|
These are just annotations in code that I'm working for this series
|
|
`ninja -l` accepts a double. We should do the same.
Bug: https://bugs.gentoo.org/810655
|
|
Otherwise, if these environment variables already exist, they will
override values we set for the developer environment.
|
|
Validate default values for KwargInfo
|
|
Because mypy doesn't like the type alias.
|
|
|
|
Because currently you can write something like:
```python
KwargInfo('capture', bool)
```
Which proclaims "this must be bool", but the default is then not valid.
|
|
The correct way to mark these is `KwargInfo(..., (T, type(None)))`.
There's also a few cases of `(T, None)` which is invalid, as `None`
isn't a type
|
|
There was a copy-n-paste error here, and it was benchmark instead.
|
|
|
|
|
|
This is quite valuable for enum-like inputs, where only a certain set
of values is allowed.
|
|
Exception is thrown when dependency name is empty and when its
'include_type' differs from the default one.
Regression from b6d754a40c.
|
|
The sysconfig paths are, by default, correct for every OS -- they are
supposed to follow the scheme that python knows about per default.
For some reason, this overrode the scheme to posix_prefix, which is the
default for posix OSes like linux and macOS, but wrong on Windows.
Simply deleting this entirely makes everything that used to work, still
work, and a couple new things start working.
|
|
|
|
The tool needs to run the preprocessor (but does not actually produce
compiled outputs), and meanwhile ignores lots of flags it doesn't think
it needs. In the case of -D_FORTIFY_SOURCE=... this is only valid if -O
is there too, but otherwise spits out confusing warnings.
The warnings are spurious and can be safely ignored, but in this case
let's go the extra mile and fix g-ir-scanner's upstream bug by removing
the fortify flag first.
Fixes #9161
|
|
It should apply to the *next* stable release.
Reported-by: Tristan Partin <tristan@partin.io>
|
|
It should build the fallback subprject with default_library=static and
override the dependency for both static=True and static kwarg not given.
Fixes: #8050.
|
|
|
|
Follow-up on commit 5a7b8d86d0c455680096d47cb87f0de08c0954ac
Sometimes, we find a parent meson.build which is also malformed, and we
shouldn't suggest that maybe the user meant to use that, if it isn't a
valid project() either. Do a rough and dirty check to see if the very
first line is a project() declaration, and if not, don't try to be
clever and suggest using it.
The "invalid source tree" error suffices here, since we're not
absolutely sure meson can be successfully run in that parent directory
and actually advising people about the wrong location is a lot more
confusing than just saying "please figure this out yourself, here is
what to look for".
Granted, we miss cases where project() comes after blank lines and/or
comments, but doing a full AST parse here is excessively overkill and
probably too painful to do, and we don't need to be *that* clever. So
let's be content with merely going above and beyond the call of duty.
|
|
The Java module will serve as a source for easing Java development
within Meson. Currently it only supports generating native header files.
|
|
|
|
|
|
One percent-formatted string had a .format() method style placeholder
and thus never output anything other than
TypeError: not all arguments converted during string formatting
The other error may be due to changing format elsewhere, because it
attempted to treat an entire tuple as though it only contained one
element. Based on context, it's clear this is supposed to be the actual
dependency name, but the internal representation may have changed over
time.
These fixes allow the command to run to completion successfully; of
course it is still unstable and possibly not actually maintained, since
it's been broken for 2 years and no one actually noticed.
|
|
Explicitly mention that the project definition is invalid, and clarify
that project is `project()` -- a function.
Also try to walk the directory tree upward, and if there are parent
meson.build files, just say this isn't the project root, and "maybe you
meant to run meson there instead?"
This won't catch calls to subdir('foo/bar') but we can't be perfect,
only better than before and catch the *majority* of such cases, and
hopefully it's a lot more clear if meson protests that the project is
"invalid, there is no project() function", where the user should look
for a potential solution.
Fixes #3426
|
|
We recommend people use declare_dependency and access it via
dependency() in a parent project. But this requires a wrap file (or to
use override_dependency and an explicit subproject call).
Let's actually mention that.
Fixes #9146
|
|
|
|
|
|
|
|
|
|
Qt module generated sources
|
|
Which is easier to reason about as a human, and narrower, allowing for
more accurate type checking.
|
|
|
|
There are cases in the backend like this:
```python
e = ExecutableSerialisation(...)
e.verbose = v
```
setting it from the initializer is cleaner.
|
|
|
|
|
|
|
|
|
|
|
|
|
