I've combined the two ppc checks into one, since they're not very
complicated and added power machintosh, which is used by PPC macs
running older versions of osx.
Fixes: #6746
Rather than having two separate sections with duplicated information
lets just have one for the common settings, and only document sections
specific to each file in separately
The previous diagnosis (that the wrapper that injects the -target
option to clang caused the issues) doesn't seem right; the issue
was that LLD's MinGW frontend (which is invoked when ld.lld is given
a COFF argument to the -m option) didn't handle the --version argument
before LLD 9.0.0.
PR #6363 made it so our interpretation of env vars no longer clashed
with Autoconf's: if both Meson and Autoconf would read and env var, both
would do the same things with the value they read.
However, there were still cases that autoconf would read an env var when
meson wouldn't:
- Autoconf would use `CC` in cross builds too
- Autoconf would use `CC_FOR_BUILD` in native builds too.
There's no reason Meson can't also do this--if native cross files
overwrite rather than replace env vars, cross files can also overwrite
rather than replace env vars.
Because variables like `CC` are so ubiquitous, and because ignoring them
in cross builds just makes those builds liable to break (and things more
complicated in general), we bring Meson's behavior in line with
Autoconf's.
This makes use of proper ConfigTool and PkgConfig dependencies rather
than one big ExternalDependency that internally creates other
dependencies and then copies their attributes.
Basically this breaks down into three cases. An open source version with
compliant PkgConfig, valid CMake, and a Intel implementation that has
completely broken PkgConfig. For the first two cases we can use standard
classes, for the last we can make a subclass of PkgConfigDependency that
handles the special logic.
This doesn't change any of the logic, but it does re-organize it to be
clearer, and make use of the dependency factory API, which makes other
things (like Dependency.get_variable) work.
This is untested with Intel MKL.
This make relative pathes shorter an too give a chance to
de-duplicate -isystem flags just like -I flags.
Fix common test case 203 for OSX build host too
If no exe_wrapper is set in the meson cross file the exe_wrapper
object will be an instance of EmptyExternalProgram.
So, found is True and prorgram is an empty list.
This will cause meson to tun the compiler sanity check because
it checks only for self.is_cross and self.exe_wrapper being
not None.
I ran into that situation while cross compiling for ia32 on a
x64_64 host. The host had no ia32 userspace installed, so the
self test failed.
As workaround I currently set exe_wrapper to 'true'.
Signed-off-by: Richard Weinberger <richard@nod.at>
Xavier Claessens