Guidance for using Meson #449
Replies: 3 comments 10 replies
-
|
The meson project maintains a database of wraps.
|
Beta Was this translation helpful? Give feedback.
-
|
@WillAyd Writing a build system that compiles and links Did you check that the compiler+linker flags are identical when using meson vs cmake? I'm hesitant to advertise this here if it's not following the best practices. "The extension works" is a good start but not the target. |
Beta Was this translation helpful? Give feedback.
-
|
OK thanks for that info. I created a very minimal repo that has both CMake and meson build systems: https://github.com/WillAyd/nanobind-meson When looking at the comments you have in For the extension module, the flags depend on how you have chosen to set up meson. A release build uses the same flags as the nanobind library, but a debug build (from As far as linker arguments, it does not look like Meson uses Sample CMake verbose build: $ VERBOSE=1 cmake --build build Run Build Command(s): /home/willayd/mambaforge/envs/pantab-dev/bin/ninja -v Sample meson output (release build): $ meson compile -v |
Beta Was this translation helpful? Give feedback.
-
|
This is all from a linux box. I don't have access to other platforms to check the flags that get produced, but am hopeful the (relatively) same alignment would be preserved there |
Beta Was this translation helpful? Give feedback.
-
|
On macOS, there is an extra complication involving a linker response file that nanobind uses to enable a linker optimization called "chained fixups" |
Beta Was this translation helpful? Give feedback.
-
|
Ah interesting - so you see that issue using Meson in the sample repo I provided right? Happy to report that upstream if we can craft more details; the meson team tends to be pretty responsive. It may already even be on the radar for @eli-schwartz |
Beta Was this translation helpful? Give feedback.
-
|
The interface library provided by nanobind -- meson calls this a "declared dependency" -- can provide compile flags (including macro defines) as well as link flags which the A dependency such as nanobind doesn't have the ability to change whether, for example, meson builds a limited API vs a regular extension module. That would change the output filename of the build target that meson "owns". If nanobind has to make decisions about how it builds, depending on how the extension modules themselves build, then it may make sense to provide multiple interface libraries. I don't know whether that is relevant. Things like LTO, NDEBUG, or optimizations could be injected via the interface library compile flags, but it's really best not to. Someone might want to debug their own code (including their code as modified by nanobind templates or macros) but not the nanobind library code. Or they might not be LTO-safe even when nanobind object files are LTO-safe. Linker response files should be fine as long as they are exposed as linker flags in the interface library. If they are being added only via a cmake user function that wraps around adding a library and setting target link arguments then that information isn't available for meson to introspect. There are probably things I haven't talked about. I've not read the nanobind cmake files. Feel free to ask me questions about specific details that nanobind may be doing and which need to somehow be represented in meson. |
Beta Was this translation helpful? Give feedback.
-
|
@wjakob do you have any opposition to creating a WrapDB entry for nanobind in Meson? Ideally we would add the meson.build files to this repo directly, but if that's not something you care for I think we could also just add them upstream to Meson's WrapDB. I am happy to lead that contribution either way Meson and meson-python have picked up momentum in the scientific python space (pandas, NumPy, and SciPy all use those tools) so having an easy way to install nanobind with Meson projects I think would be a great asset to the ecosystem |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the late reply. I have no opposition at all, if it's something that is separate from this repository. Once there is a well-established process, it could also be advertised in the documentation. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome thanks! The wrapdb entry should be the best solution to this issue: If you have any more feedback on that would be great to post there. Otherwise I think just need to wait for the next nanobind release or MSVC compiler that fixes #613 before that gets merged to the wrapdb |
Beta Was this translation helpful? Give feedback.
-
Since quite a few libraries in the scientific python stack use meson as a build tool, I wanted to share what I've found to be a viable solution to integrate nanobind into a meson build system. Much of this was inspired by the discussion on the meson-python discussions page
For starters, Meson requires you to create a subprojects folder at the top level of your project. Therein you can create a wrap file that looks something like this:
Be sure to change the revision above and the target name to fit your needs. Meson does not know the name of the dependency that CMake generates, so the
dep_name = <target_name>_depsyntax is required in the provide section.Within your meson file(s) you can then use the dependency when building extension modules:
Beta Was this translation helpful? Give feedback.
All reactions