Summary: | dev-python/meson-python-0.14.0: failed (compile phase): error: Could not find ninja version 1.8.2 or newer. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joonas Niilola <juippis> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | base-system, eschwartz |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Joonas Niilola
![]() Created attachment 870272 [details]
build.log
Right, meson doesn't RDEPEND on ninja (which feels kind of dubious, it should depend on ninja or samurai). I suppose meson-python itself should also RDEPEND on either of those: https://github.com/mesonbuild/meson-python/blob/b4d42400b06f0f23420048dfe46e71a66f7fe54d/mesonpy/__init__.py#L925. It is technically possible for meson to use xcode on macOS but this would only ever affect people installing it in Gentoo Prefix and then using meson interactively. meson.eclass adds in ${NINJA_DEPEND} so use of meson in an ebuild is theoretically covered. (It's also possible for projects that have no build rules, only install rules, to configure meson with -Dbackend=none and skip ninja. This has limited usefulness, but some projects might in fact want to use meson as a powerful install tool for installing pure data files, such as *.py files... that's why I implemented the "none" backend.) Whether it's valuable to make that distinction, I do not know. It's not a very heavy dependency either way, and the default behavior of meson is to always assume ninja and mandate it unless you go out of your way to select an alternative backend. |