The job is taking too long and timing out, use pytest-xdist to speed
up unit tests. Speeds it up on my system from 20 min to 8 min.
Still much slower than native windows: vs2017-x64 takes 3.5 min with
pytest-xdist.
Run docker with seccomp:unconfined, since otherwise we're blocked from
calling CreateToolhelp32Snapshot() inside the cross-mingw tests,
specifically `common/122 shared module`.
There are two problems, one is that it assumes -flto is the argument
to do LTO/WPO, which isn't true of ICC and MSVC (and presumably)
others. It's also incorrect because it assumes that the compiler and
linker will always be the same, which isn't necessarily true. You
could combine GCC with Apple's linker, or clang with link.exe, which
use different arguments.
I started out just annotating, but realized there is a lot of really
silly duplication of methods in this module. Nearly all of the methods
return [], but each class implemented the same methods over and over!
I've fixed this by moving the default implementation down into the
`StaticLinker` class, and then overriding as necessary in the derived
classes.
This is used in a lot of places, having a single way to reference it is
convenient. It's placed under a typing.TYPE_CHECKING guard to mimimize
runtime impact
@TingPing has a repository that contains a grammar for meson which is
used by linguist (GitHub), and by many editors such as Atom, VS Code,
TextMate, Sublime Text, etc. Add CI so that we notice that the
function list in it is out of date, such as https://github.com/TingPing/language-meson/pull/3
It's harder to do this generically for other syntax such as the `in`
keyword, but it's better than nothing.
This reverts the changes to the `section` key for the
buildoptions and moves the machine choice into it's
own `machine` key.
With this commit the __undocumented__ breaking change
to the introspection format (introduced in 0.51.0) is
reverted and a new key is added instead.
* gtkdoc: Add 'check' kwarg
This runs gtkdoc-check in meson tests.
Also reorganize the gtkdoc test because we cannot reliably build
multiple doc into the same directory. Not all files generated by gtk-doc
are prefixed with the target name.
Error example:
Code:
#include <locale.h>
int main () {
/* If it's not defined as a macro, try to use as a symbol */
#ifndef LC_MESSAGES
LC_MESSAGES;
#endif
}
Compiler stdout:
Compiler stderr:
In file included from /usr/include/locale.h:25,
from /tmp/tmpep_i4iwg/testfile.c:2:
/usr/include/features.h:382:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
382 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
| ^~~~~~~
/tmp/tmpep_i4iwg/testfile.c: In function 'main':
/tmp/tmpep_i4iwg/testfile.c:8:9: error: control reaches end of non-void function [-Werror=return-type]
8 | }
| ^
cc1: some warnings being treated as errors
Instead of trying to guess whether we need py or python3, and then
falling over when whatever we guessed isn't in the path or isn't right,
just use sys.executable which should always work.
There is a pretty big error in here, trying to return a tuple
comperhension: (a for a in []) is not a tuple, it's a generator. This
has profound type annotations: generators don't support most tuple or
list methods, and they can only be iterated once. Beyond that tuples are
meant for heterogenous types, ie, position matters for types. I've
converted the output to a list in all cases.
Daniel Mensinger
Nirbheek Chauhan
Jussi Pakkanen
Marc-André Lureau
Dylan Baker
Jeremy Philippe
Xavier Claessens
Michael Hirsch, Ph.D
Xavier Claessens
ailin-nemui
Michael Hirsch, Ph.D
ePirat
Martin Liska