`from foo import` should be used sparingly because of namespace
pollution, especially since those names will be exported
unconditionally. For typing this is extra annoying because anytime
someone wants to use another symbol from the typing module they have to
add it to the import line. Use `import typing` to avoid all of this.
There are three problems:
1) Dunders like `__lt__` and `__gt__` don't return bool, they return
either a bool or the NotImplemented singleton to signal that they don't
know how to be compared.
2) The don't take type object, the take `typing.Any`
3) They need to return NotImplemented if the comparison is not
implemented, this allows python to try the inverse dunder from the
other object. If that object returns NotImplemented as well a
TypeError is raised.
The 'output' field of the subprocess.CalledProcessError exception is
valid only when subprocess.check_output() is called, trying to access it
after calling subprocess.check_call() results in an unwanted exception
when commands return non-zero exit code, e.g.:
-----------------------------------------------------------------------
$ meson subprojects foreach false
Executing command in ./subprojects/sqlite-amalgamation-3250100
-> Not downloaded yet
Executing command in ./subprojects/gstreamer
Traceback (most recent call last):
File "/home/ao2/meson/meson/mesonbuild/msubprojects.py", line 177, in foreach
subprocess.check_call([options.command] + options.args, cwd=repo_dir)
File "/usr/lib/python3.7/subprocess.py", line 363, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['false']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/ao2/meson/meson/mesonbuild/mesonmain.py", line 129, in run
return options.run_func(options)
File "/home/ao2/meson/meson/mesonbuild/msubprojects.py", line 248, in run
options.subprojects_func(wrap, repo_dir, options)
File "/home/ao2/meson/meson/mesonbuild/msubprojects.py", line 180, in foreach
out = e.output.decode().strip()
AttributeError: 'NoneType' object has no attribute 'decode'
-----------------------------------------------------------------------
Use subprocess.check_output() instead and behave more like git commands
in handling stderr.
This makes it possible to actually run commands on all subprojects
allowing them to fail on some subprojects and succeed on others.
Also catch the case of missing commands and print an error message in
this case as well.
Some slight refactoring for the dependency classes and
I switched the elbrus compiler to the GnuLikeCompiler.
This is also the correct use according to the documentation
of GnuLikeCompiler.
This puts appropriate default options across buildtype for Intel and
Intel-Cl compilers, for C, C++ and Fortran. Prior to this PR, the
behavior of Intel compilers vs. GNUlike was not the same, in
particular, debug traceback available by default for GNUlike compilers
was not present with Intel compilers.
Fixes PR #6166 and more specifically commit 4e460f04f3 that tried to
make sure the type of a key variable is a string but checked the type of
the value instead. Extends test common/228's limited coverage,
its only test case had (surprise) a string value. Also avoid reserved
python keyword 'dict' and potentially confusing string 'key'.
Implements #5231 for real.
This is returning the inverse of the correct value, which happens to
work out because in general the compilers that a link.exe-like linker is
paired with accepts the same arguments.
This dumps xild on mac and linux. After a lot of reading and banging my
head I've discovered we (meson) don't care about xild, xild is only
useful if your invoke ld directly (not through icc/icpc) and you want to
do ipo/lto/wpo. Instead just make icc report what it's actually doing,
invoking ld or ld64 (for linux and mac respectively) directly. This
allows us to get -fuse-ld working on linux.
Since I spent three days banging my head against this it seems
reasonable that other people might also run into this problem. It can
happen if you're trying to use microsoft's link.exe, but also have the
dmd bin directory at the tail of your %PATH%, among other reasons.
Since we pass the whole compiler class (as a type()) we don't need to
also pass it's LINKER_PREFIX attribute, we can just get it from the
type we're passing.
Rather than trying to figure out if we're using MSVC based on
environment variables, then trying to get the C compiler and test some
attributes, get the C compiler and see if it's MSVC. This is much more
reliable and we were already doing it anyway.
Dylan Baker
Antonio Ospite
Jussi Pakkanen
Amit D
Daniel Mensinger
Danilo Spinella
Xavier Claessens
Michael Hirsch, Ph.D
Michael Brockus
Marc Herbert