Emscripten has pthread support (as well as C++ threads), but we don't
currently implement them. This fixes that by adding the necessary code.
The one thing I'm not sure about is setting the pool size. The docs
suggest that you really want to do this to ensure that your code works
correctly, but the number should really be configurable, not sure how to
set that.
Fixes#6684
This is more correct, and forces the target(s) to be rebuilt if the
PDB files are missing. Increases the minimum required Ninja to 1.7,
which is available in Ubuntu 16.04 under backports.
We can't do the same for import libraries, because it is impossible
for us to know at configure time whether or not an import library will
be generated for a given DLL.
Instead of checking the compiler id inside the VisualStudioLikeCompiler
class, this creates two subclasses that each represent the divergent
behavior of the two compilers
* environment: Fix passing always args to a number of less common linkers
These are mostly (oops xilink) proprietary linkers I can't use for
various reasons.
Fixes: #6332
* Add intelfix from scivision.
* Ifort fix from scivision.
* PGI fix from scivision.
* Cuda fix from scivision.
* Fix linker passing for armclang.
this can be useful for if/elif where linker behaviors must be
considered.
For example, clang with "link" vs gcc with "ld.bfd" etc.
ci for compiler.get_linker_id() method
doc
add @FeatureNew check
Co-Authored-By: Daniel Mensinger <daniel@mensinger-ka.de>
intel compiler's defaults are different enough from MSVC and GNU
that it's necessary to set specific defaults for Intel compilers.
This corrects/improves behaviors initially addressed in b1c8f765fa
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll
get ld.gold, not whatever the default is. Meson currently doesn't do
that, because it doesn't pass these arguments to the linker detection
logic. This patch fixes that. Another case that this is needed is with
clang's --target option
This is a bad solution, honestly, and it would be better to use $LD or a
cross/native file but this is needed for backwards compatability.
Fixes#6057
Currently this is done at the instance level, but we need it at the
class level to allow compiler "lang" args to be gotten early enough.
This patch also removes a couple of instance of branch/leaf classes
providing their own implementation that is identical to the Compiler
version.
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.
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.
Since version 9.1, GCC provides support for the D programming language. Thus it
is easy to build a cross-compiler for D, such as aarch64-unknown-linux-gnu-gdc.
However to cross-compile a Meson project using D, using a cross build definition
such as the following is not enough:
```
[binaries]
d = '/path/to/aarch64-unknown-linux-gnu-gdc'
exe_wrapper = '/path/to/qemu-aarch64-static'
[properties]
needs_exe_wrapper = true
[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'cortex-a53'
endian = 'little'
```
Indeed, "exe_wrapper" is not be taken into account. Build will fail with:
```
Executables created by D compiler /path/to/aarch64-uknown-linux-gnu-gdc are not runnable.
```
This patch fixes this by reworking:
- detect_d_compiler() to properly get exe_wrapper and D compilers and detect the
one available.
- Dcompiler to properly handle exe_wrapper.
It would be very challenging if not futile to make has_function work for Fortran.
The meson.get_compiler('fortran').links() works very well instead.
As a reference, CMake's check_fortran_function_exists is completely broken in general.
This change raises a useful MesonException instead of giving bizarre errors.
Dylan Baker
Nirbheek Chauhan
alanNz
makise-homura
Daniel Mensinger
Jussi Pakkanen
Michael Hirsch, Ph.D
Antoine Jacoutot
Xavier Claessens
Eric Le Bihan
Michael Hirsch, Ph.D
Wolfgang Stöggl
Aleksey Gurtovoy