We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
This didn't actually catch what it's supposed to, which is cases of:
```python
for x in dict.keys():
y = dict[x]
```
But it did catch one unnecessary use of keys(), and one case where we
were doing something in an inefficient way. I've rewritten:
```python
if name.value in [x.value for x in self.kwargs.keys() if isinstance(x, IdNode)]:
```
as
``python
if any((isinstance(x, IdNode) and name.value == x.value) for x in self.kwargs):
```
Which avoids doing two iterations, one to build the list, and a
second to do a search for name.value in said list, which does a single
short circuiting walk, as any returns as soon as one check returns True.
Currently, EnvironmentVariablesObject is a strange
holder-that's-not-a-holder. This has implicaitons for things that expect
to get an EnvironmentVariables object, as we can't automatically
unholder it, and instead have to to manually do so. Now we can
automatically unholder it, which makes everything much nicer.
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 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 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 5a7b8d86d0
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.
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
Dylan Baker
Eli Schwartz
Xavier Claessens
Mike Gilbert
Ting-Wei Lan
Jussi Pakkanen
Rihards Skuja
Tristan Partin