| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
The clang compiler now reimplements and re-checks the c_std and cpp_std
options in order to use them for objc as well, but it didn't
consistently support the same options. First it completely excluded all
the gnu ones, and then it added a handful of them but not for C++.
Be fully consistent -- or at least as consistent as we can be, given a
minimally working fix. (The C/C++ compiler mixin actually gates
different stds depending on detected clang version, we do not do that
here.)
Fixes regression in c54dd63547b030e3d9feee694ec6f49c434f0df8
Fixes incomplete fix from #8766 (which didn't fix objcpp at all)
Fixes #9237
|
|
This requires a bit of extra code because the version might change, but
otherwise it fits in the existing AllPlatformTests.test_summary testcase
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Dependencies are currently printed as
[<mesonbuild.mlog.AnsiDecorator object at 0x7faa85aeac70>, ' ', <mesonbuild.mlog.AnsiDecorator object at 0x7faa85aeab50>]
This was introduced in commit adb1b2f3f6ad54b346348ec6e5b8d96f2f7ba0a6, due to
an incorrect type annotation on the AnsiText constructor. Fix both the
annotation and the usage.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
|
|
Allow using the links method to test that the C++ driver (e.g. g++) can be used to
link C objects. One usecase is that the C compiler's libsanitizer might not be
compatible with the one included by the C++ driver.
This is theoretically backwards-incompatible, but it should be treated as a
bugfix in my opinion. There is no way in Meson to compile a .c file with the
C++ driver as part of a build target, therefore there would be no reason to
do something like meson.get_compiler(meson.get_compiler('cpp').links(files('main.c')).
Fixes: #7703
|
|
In some cases, link tests would like to use objects provided by a compiler
for a different language, for example linking a C object file with a C++
compiler. This kind of scenario is what link_language is for, but it is
impossible to test that it works with a linker test.
This patch implements the required support in the Compiler class. The
source code compiler is passed to the Compiler.links method as an
argument.
|
|
The type information allows it, but it is not actually handled.
|
|
|
|
Signed-off-by: Filipe LaÃns <lains@riseup.net>
|
|
This also removes the additional upload step for test results
in the hope of fixing the `autoCancel` flag.
|
|
|
|
|
|
Fixes #8792
Fixes #8733
|
|
I have a local configuration
tag.forcesignannotated=true
commit.gpgsign=true
This causes the tests to fail with e.g.
error: gpg failed to sign the data
fatal: failed to write commit object
Since this is a unittest, it is never wrong to tell git "just ignore
prior configuration, and disable all PGP signing".
|
|
Fixes various inconsistencies:
- gitattributes is respected
- export-subst
- export-ignore
- submodules with relative paths are not checked out relative to the
local clone (which does not work anyway)
- no need to manually remove gitfiles with inaccurate heuristics
Fixes #2287
Fixes #3081
Fixes #8144
|
|
WSL 2 removes the "Microsoft" from `platform.version` but leaves it inside `platform.release`. This lets us detect both types of WSL without issue.
|
|
"ERROR: Git program not found" is both highly true, and somewhat
inscrutable. Sure, looking at the line number you can basically figure
out that subproject('something') must somehow need git to operate, but
that may not be immediately obvious.
Make mention of the fact that it is needed to "download foo.wrap".
Fixes #7764
|
|
It is a commonly needed information to help debugging build issues. We
already were printing options with non-default value at the end of the
configure but outside of the summary.
Keeping the list of user defined options in the interpreter will also in
the future be useful to use new default value on reconfigure.
|
|
When sorting options we want the same order as they are presented in
"meson configure" command.
|
|
And more accurate too, TBH. Currently it says it is building "lang.mo",
even though it is actually building "domain.mo" inside
lang/LC_MESSAGES/.
Since meson loudly complains if I try to name the display name
"lang/domain.mo", name it with a dash instead of a slash. The actual
name isn't a priority here IMO, and this is nicely readable.
|
|
We've now fixed it so it works, and it provides useful functionality,
e.g. creating a custom target that builds multiple gettext domains in
one action.
|
|
It has no command, so you cannot try printing it or it explodes with
IndexError: list index out of range
|
|
A run_target object created in a subdir/meson.build always has a ninja
rule name of "name", not "subdir/name".
Fixes #9175
|
|
That used to abort in previous Meson versions but 0.59 stopped
forbidding that by mistake.
|
|
* compilers: improve docstring to `get_compiler_check_args()`
There was an incomplete list, which wasn't useful as it now takes an
enum anyway. Also add a new entry to the list of reasons to use this
function.
* clang: Add -Werror=implicit-function-declarations to check_args
Unlike GCC, clang warns but doesn't error when an implicit function
declaration happens. This means in checks like
`compiler.has_header_symbol('string.h', 'strlcat')` (on Linux, at least)
that GCC will fail, as there is no such function; clang will emit a
warning, but since it exists with a 0 status Meson interprets that as
success. To fix this, add `-Werror=implicit-function-declarations` to
clang's check arguments.
There seems to be something specific about functions that _may_ exist in
a header on a given system, as `cc.has_header_symbol('string.h',
'foobar')` will return false with clang, but `strlcat` will return true,
even though it's not defined. It is however, defined in some OSes, like
Solaris and the BSDs.
Fixes #9140
|
|
|
|
|
|
These operators don't make sens to use in ObjectHolders, since
this mechanism wouldn't allow for lazy evaluation.
|
|
|
|
Currently every project that uses UTF8 for its source files must add
'/utf-8' argument otherwise they don't work non-English locale MSVC.
Since meson.build itself is assumed to be UTF8 by default, seems better
to assume it for source files by default too.
For example:
- https://gitlab.freedesktop.org/gstreamer/gst-build/-/blob/master/meson.build#L62
- https://gitlab.gnome.org/GNOME/glib/-/blob/main/meson.build#L29
|
|
Removed in commit 487d45c1e5bfff0fbdb4747841db6a0b5b124af9 but perhaps
it should not have -- people may have been depending on ensuring those
are built somehow. Even though the internal implementation changed and
it is now built by the all target, let's keep the old target around too.
Now it just aliases the actual build rules, though.
|
|
Users may wish to make use of these files for their own purposes.
For example, the -pot and -update-po pseudo targets could be reused in
an alias_target(), and at least one person wanted to reuse the built .mo
files as custom_target input.
Fixes #6227
|
|
This simplifies things for us, as we don't have to have threading
imported for no other reason, and we can remove the
`an_unpicklable_object` from the Interpreter and mesonlib, since there
was only one user of this.
|
|
We want this, so let's test it.
|
|
|
|
|
|
|
|
This caught a couple of cases of us doing:
```python
for i in range(len(x)):
v = x[i]
```
which are places to use enumerate instead.
It also caught a couple of cases of:
```python
assert len(x) == len(y)
for i in range(len(x)):
xv = x[i]
yv = y[i]
```
Which should instead be using zip()
```python
for xv, yv in zip(x, y):
...
```
|
|
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.
|
|
Which is really useful for catching parens used with keywords like
assert. Don't use parens with assert, it's bad.
|
|
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.
|
|
This finds things like
```python
if not x == 1:
```
which should be
```python
if x != 1:
```
|
|
Make EnvironmentVariablesObject a holder
|
|
Handle aarch64_be as a cpu family
|
|
* Make assignment a statement in Syntax
force to change line 709 to something kind of non sensical
* Applied code review changes
|
|
We use distutils, not setuptools, for probing information.
|
|
This is more consistent with other Holder classes
|
