This partially reverts commit fe853ee516.
In particular this reverts the changes to the DynamicLinker __init__
methods. Frankly this is *bad* because it allows a mixin class (which
should not be directly instantiated) to be directly instantiated, and
complicates the init process. It also increases the amount of code for
zero gain, and makes the code less resilient to refactors.
There are two awful things about CompilerArgs, one is that it directly
inherits from list, and there are a lot of subtle gotcahs with
inheriting from builtin types. The second is that the class allows
arguments to be passed in whatever order. That's bad. This also fully
annotates the CompilerArgs class, so mypy can type check it for us.
`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.
Visual Studio refuses to open projects that present duplicated
items, for example:
<ItemGroup>
<CLInclude Include="glib-enumtypes.h"/>
<CLInclude Include="glib-enumtypes.h"/>
</ItemGroup>
Note that MSBuild handles duplicated items without any issue,
this is useful only for compatibility with the VS IDE.
See pull request mesonbuild#6151
Fixes issue mesonbuild#6147
This PR refactors the old output_target_map, which was a
raw dict, into it's own class. This makes the access to
the map more uniform and robust (at the cost of more lines
of code).
Additionally relative paths to the build directory are
now also tracked for outputs. This is neccessary to
corretcly distingluish files with the same name, that are
in different directories.
The linker implementation split up introduced a regression: since the
AppleDynamicLinker subclass doesn't expose PIE support, builds using
that feature just plainly fail.
Add back support for it using the default and supported -pie flag.
507cf47507cf47 broke the combination of clone-recursive without depth.
Because it passed depth (as None) to git.
To fix this the depth option is now generated once as a list when depth is set
and else set to an empty list and unpacked into the argument this when
needed. This reduces duplication and allows code to work the same for
both cases.
This addresses various real-world problems with HDF5 pkg-config, including
* hdf*.pc with package versions as part of the filename
* malformed hdf*.pc missing the commonly-used HDF5 HL module
---
Additionally, this refactors more complicated dependencies such as
HDF5 and OpenMPI. This may help us deduplicate internal dependency
code in the future.
HDF5 selftest: improve platform-agnostic test
ci: init demo github action for HDF5 framework
ci Actions: hold off on MSYS2 for now [skip ci]
hdf5: ensure C libraries always included
ci: mac hdf5--use clang+gfortran
When lrelease-qtN is missing, upgrade the error message from the
cryptic:
meson.build:75:4: ERROR: Tried to use not-found external program in "command"
to the meaningful:
meson.build:75:4: ERROR: qt.compile_translations: lrelease-qt5 not found
Issue found and tested with "test cases/frameworks/4 qt/"
t.pic won't be defined. We can only hope it has been built with -fPIC.
Linker will complain otherwise any way.
t.extract_all_objects_recurse() won't be defined. We could support this
case by extracting the archive somewhere and pick object files.
Refactor the code inside a common function for consistency.
It's not needed to add dependencies in func_configure_file() because
it's already done in run_command_impl(). Do it only for files from
`input:` in the case some of them does not end up in the command
arguments.
We might be using the 32-bit bits of the VulkanSDK on Windows on x64
Windows, so we still need to pass in the compiler items to detect what
architecture we are building for, so that we link to the correct Vulkan
libraries.
We might want to look into this again if Microsoft will allow ARM/ARM64
versions of the Vulkan drivers and SDK, since post-basic OpenGL and
any Vulkan are not supported on Windows-on-ARM.
Xavier Claessens
Dylan Baker
Antonio Ospite
Jussi Pakkanen
Daniel Mensinger
Michael Hirsch, Ph.D
Michael Brockus
Marc Herbert
Luca Bacci
taz-007
Mihai Moldovan
Xavier Claessens
Nirbheek Chauhan
Martin Hostettler
Chun-wei Fan