#meson-python
1 messages · Page 1 of 1 (latest)
What is the status of bundling native extension on Windows with meson-python?
Currently, only Linux supports it and a PR is on the way to support Mac
not a priority right now
but you can work around it by just using static libraries!
@outer veldt sorry for the late reply
I recently ran into the problem that nanobind+meson-python+stable-ABI currently don't play nicely together (any two of the three is fine, but all three together is not, as nanobind gets built with different settings from the extension module, so the build dies with a linker error): https://github.com/mesonbuild/wrapdb/issues/1758
However, I'm not clear on if this is something the wrapdb entry for nanobind could be updated to handle, or if it requires changes to meson-python itself (my interim workaround is to drop the "stable ABI" part of the problematic trifecta).
my reading on the meson issue would indicate that it's a meson bug
The original limited API handling in meson didn't foresee the use of static libraries using the cpython API and implemented an express mode for extension modules but nothing for common utility libraries such as nanobind. This could be manually handled via hardcoded flags but we should probably add an API for it.
I guess it depends what the wrapdb actually contains
ah, I think it could be done -- https://github.com/mesonbuild/wrapdb/blob/master/subprojects/packagefiles/nanobind/meson.build has all the meson wrabdb contents
And the stack of potential yak shaving tasks from my current work project gains another entry (I do not expect to get to any of them anytime soon, though, since they all have workarounds that are simpler than tackling the root cause)
so many yaks
it looks like there's a few things meson does to support limited API, but probably for a static library it just requires setting the right macro. https://github.com/mesonbuild/meson/blob/c85c5f488782a1365c5fbc5f9c69c4b722ed0a24/mesonbuild/modules/python.py#L178
probably the easiest thing to do for the wrapdb would be to add a second library to link against that has that flag
maybe get_option
I haven't used wrapdb yet
for meson, can i set an enviroment variable to limit how many jobs it uses?
i'm not finding that info easily in the docs
https://mesonbuild.com/Unit-tests.html#parallelism MESON_NUM_PROCESSES apparently
although maybe that’s only meson’s unit tests?
it seems to be poorly documented, it does show up in a couple other spots though
according to the docs, it should be respected for other things too:
though now i think that ninja's being launched with many jobs, or meson is doing that, tried looking for a similar env variable for ninja:
https://github.com/ninja-build/ninja/issues/1482
but it looks like ninja devs really didn't want to add a env var limiting jobs number
https://paste.pythondiscord.com/RKNA
Is it possible to finally add the support for an environment variable that would limit the maximum number of jobs ninja can spawn? I would suggest having an optional environment variable NINJA_NUM_...
most things don't have wheels for the python i'm trying to build for so some build systems need to be patched, guess will have to dig deeper and patch here too for meson
the one big downside of meson is that if it doesn’t have what you need then the only option is to patch it and send in a PR - otoh it’s kind of an upside too because e.g. cmake’s extensibility is a tar-pit
I forget exactly what I was attempting to do, but Google's AI bot insisting that meson had an option that simply doesn't exist was my first real world encounter with an AI hallucination that genuinely wasted a chunk of my time.