Developer experience

[friendlyanon]

nanobind makes the very curious choice of making the consuming project build its source files instead of being distributed in a binary form first. This also comes with several drawbacks:

• nanobind's source files may emit warnings, which may end up becoming errors (e.g. due to warnings-as-errors flags).
• Compiled nanobind may never be cached reliably.
• nanobind doesn't present its usage requirements (i.e. includes) as SYSTEM.

The first one will never be properly addressable, since projects may not assume what warnings (or compilers) consumers have. Noone can predict everything that will ever be.

For the second one, unless you have nailed reproducible builds down to a T, it's useless to even begin thinking about this. While nanobind indeed aims to be nano, additional project wide static analysis tools that normally run alongside compilation will increase the cost of compiling nanobind in every CI run. clang-tidy for example has a CMake integration and can take a bit of time to run alongside normal compilation. It's also non-trivial to skip these static-analysis tools for just nanobind.

The last one is trivial to fix. Just add SYSTEM to target_include_directories according to its docs. This prevents users of major compilers to receive warnings in their code about issues coming from nanobind's headers.

A nice-to-have feature would be adding an ALIAS target for nanobind (e.g. nanobind::nanobind) to avoid the possibility of silently doing the wrong thing.

To fix the warnings coming from 3rd party sources (here nanobind) in CI, one could emulate cronic/chronic like so:

    - name: Build
      shell: bash
      run: |
        (output="$(cmake --build build -t nanobind-static 2>&1)" \
        || (printf %s\\n "$output" && false))
        cmake --build build

---

I'm also really curious what the rationale for making nanobind be built by the consuming project was. There is no explanation for this in the docs either.

[wjakob]

Hi @friendlyanon,

answers inline below.

nanobind makes the very curious choice of making the consuming project build its source files instead of being distributed in a binary form first.

You're stepping into a topic that has been very carefully considered (it's been discussed for years in the pybind11 project and nanobind is the first of the two to carry it out).

nanobind's source files may emit warnings, which may end up becoming errors (e.g. due to warnings-as-errors flags).

We want to know about these. I increased the default warning level on the CI and fixed the ones you reported. It would also be useful what kinds of warning flags you are specifying so that we can potentially add them to our CI builds.

Compiled nanobind may never be cached reliably.

The library component of nanobind is tiny (100-200kb), I don't see the issue.

nanobind doesn't present its usage requirements (i.e. includes) as SYSTEM.

Not negotiable. I want to know about those warnings, and doing so would prevent that. Nanobind publishes much finer-grained cmake commands that you could in principle also invoke/wrap separately in your project while introducing such a change.

A nice-to-have feature would be adding an ALIAS target for nanobind (e.g. nanobind::nanobind) to avoid the possibility of silently doing the wrong thing.

That sounds interesting, can you provide more detail or create a PR?

I'm also really curious what the rationale for making nanobind be built by the consuming project was.

These very old issues from the pybind11 project are the motivation.

• Header reorganization pybind/pybind11#708
• Split pybind11 into headers and cpp files to speedup compilation pybind/pybind11#2445

It would be difficult to compile nanobind on our end and then distribute the binaries. There is a big matrix of configurations (Python version, OSes, release/debug mode, static/shared). Besides that, there isn't a good way to deliver the output of this process -- for example, shipping binaries on PyPI sounds at first nice but would not work in practice as you can't have separate versions of a library installed (and the nanobind library is still evolving rapidly, some changes almost every day..)

Given how strongly you feel about all of these aspects, my suggestion would be that you choose another binding tool or create your own. It is unlikely that nanobind will be able to suitably change to accomodate your requirements.

[friendlyanon]

Interesting, I didn't know making consumers build the library was a(n at least) 6 years old idea coming from another library! I can see the benefits to be greater for a tiny library like nanobind indeed.

Given how strongly you feel about all of these aspects, my suggestion would be that you choose another binding tool or create your own. It is unlikely that nanobind will be able to suitably change to accomodate your requirements.

That would be a very silly thing to do when it's just a couple easy to fix/workaround nuisances that I have. I will have a couple PRs up.

[eirrgang]

A nice-to-have feature would be adding an ALIAS target for nanobind (e.g. nanobind::nanobind) to avoid the possibility of silently doing the wrong thing.

That sounds interesting, can you provide more detail or create a PR?

This sounds like a reference to something described in the final lines of https://cmake.org/cmake/help/latest/command/target_link_libraries.html#id3

Items containing ::, such as Foo::Bar, are assumed to be IMPORTED or ALIAS library target names and will cause an error if no such target exists. See policy CMP0028.

It is conventionally achieved for IMPORTED targets (from CMake package config modules) with the NAMESPACE argument of the install(EXPORT ...) CMake command to force a missing target to cause a fatal error instead of a silent failure. But it is also possible to just add_library(nanobind::nanobind ALIAS nanobind) in the build tree config.