macOS mistakenly ships /usr/bin/ncurses5.4-config and a man page for
it, but none of the headers or libraries are available in the location
advertised by it. Ignore /usr/bin because it can only contain this
broken configtool script. Homebrew is /usr/local or /opt/homebrew.
Xcode's command-line tools SDK does include curses, but the configtool
in there is wrong too, and anyway we can't just randomly pick it up
since the user must explicitly select that as a target by using
a native file. The MacOSX SDK itself does not include curses.
We also can't ignore ncurses5.4-config entirely because it might be
available in a different prefix.
The standard way to compile MPI applications (recommanded by all MPI implementations)
is to use the commands mpicc/mpiicc (and friends). Therefore, it is standard to
just set PATH such that mpicc points towards a wrapper of the MPI implementation
that one wants to use.
In contrast, pkg-config is supported only by OpenMPI.
Therefore, Meson has first to take into account the mpicc command to get chance
to use mpicc of MPICH or IntelMPI in the case OpenMPI is installed
(so that pkg-config would find it).
When a dependency is copied and its name is changed, we still need a way
to say "this is the same dependency", which we now have. It is
important, however, when a partial dependency is created that dependency
does *not* match the original dependency, since they are not providing
the same data. This was always happening for InternalDependencies as an
implementation detail, but not for other kinds.
These errors can make reading comments and documentation
unnecessarily confusing for users and contributors who
do not speak English as their first language.
- check version of DUB for compatibility with Meson
- use "cacheArtifactPath" to locate DUB libraries in the cache
- propose `dub build --deep` command to Meson users for missing DUB
packages
Depending on DUB version, it will look either in the old cache structure
or use this new `dub describe` entry.
It's always true because the func is always a real, truthy func object.
In the cmake case, the logic seems to be broken because if a path is not
a file, then that includes the case where it does not exist. It also
clearly meant "or" instead of "and".
What actually ended up happening was that this check never fired at all.
Because "if not func and not ..." would always fail, because "not func"
is always false. Maybe we don't need this logic at all...
The existing "*-linux-gnu*" works on the Debian multiarch model for
Linux architectures; tweak it to be "*-gnu*" so it works also for Hurd
architectures.
This makes the cmake-based search of dependencies work on Debian
GNU/Hurd.
Revert "interpreter: when overriding a dependency make its name match"
This reverts commit b1340e9bb1.
Revert "dependency: define equality and hash operators for Dependency"
This reverts commit 6d713e40f8.
This caused some projects to fail to build, such as libplacebo and
libepoxy. Taking libplacebo as the example, the produced build.ninja
does not include libvulkan.so as a linker input for
src/libplacebo.so.338.
We are probably getting dependency hashing wrong somewhere. Unsure where
exactly and unsure how to create a test case. We are also deep into rc2.
Revert it for now and try to re-land these changes for 1.6.
Bug: https://bugs.gentoo.org/935443Fixes: #13352
When building a limited API module on Windows the library
to link with should be python3.dll, not python3X.dll. This was
already the case for non-GCC, but should have been the case
unconditionally.
It was probably done this way originally since we didn't have the
`fatal` keyword argument to avoid triggering the fatal-meson-warnings.
While we're here, replace the use of a `if bool` with an `else` on the
for loop.
When trying to get the version of a program, meson was previously
hardcoded to run the binary with `--version`. This does work with the
vast majority of programs, but there are a few outliers (e.g. ffmpeg)
which have an unusual argument for printing out the version. Support
these programs by introducing a version_argument kwarg in find_program
which allows users to override `--version` with whatever the custom
argument for printing the version may be for the program.
This does a couple of things:
1. Scrape the `Py_GIL_DISABLED` sysconfig var, which is the best way as of today
to determine whether the target interpreter was built with `--disable-gil`
2. link against the correct libpython
3. On Windows, work around a known issue in the python.org installer with a
missing define in `pyconfig.h`, which the CPython devs have said is unlikely
to be fixed since headers are shared between the regular and free-threaded
builds in a single NSIS installer.
`boost_root` doesn't work if lib and include are in different directories like in the `nix` `boost` package.
The `prefix` checking could probably be removed, in 2019 conan (the
reason why the check was added) had `libdir` and `includedir` in its
generated pkg-config file
https://www.github.com/mesonbuild/meson/issues/5438#issuecomment-498761454
If there's no return then boost isn't found for some reason, further
logic is unnecessary in any case if direct paths are passed.
`roots += [Path(boost_lib_dir), Path(boost_inc_dir)]` did not work
This is in preparation for a future commit which makes it
possible for a PythonPkgConfigDependency to be used in a
context where previously only a PythonSystemDependency would
be used.
* Previously, cuda would just plainly prepend `-l` to the libname.
* By relying on the host compiler to find libraries, we now get
more subtle failures, such as CUDA modules not being found
anymore.
* We need to simplify these CUDA modules when nvcc is used for
linking, since this may have side-effects from the cuda toolchain.
Closes: #13240
* In `CudaDependency._detect_language`, the first detected language is
considered the linking one. Since `nvcc`/`cuda` implicitly know where the
cuda dependency lives, this leads to situations where `cpp` as linking
language is erroneously detected as `cuda` and then misses the `-L` argument.
This uses objfw-config to get to the flags, however, there's still
several todos that can only be addressed once dependencies can have
per-language flags.
We have seen a number of bugs from people confused by warning that the
need both a C and C++ compiler to use the CMake method. This attempts
to provide a more helpful error message.
Instead of returning Optional, a state that is only possible during
`__init__` and which prevents mypy from knowing what it is safe to
assume it will get.
It's an improper object model, but was used to signal to a subclass that
self.traceparser did not exist. However, since it is always initialized
from self.cmakebin, we can just check that instead.