CMake review

[LecrisUT]

Here's a quick breakdown of some CMake best practices

Add upper-bound to CMake policies

scikit-build-pybind11-template/CMakeLists.txt

Line 1 in 64e995f

cmake_minimum_required(VERSION 3.18)

Should be

cmake_minimum_required(VERSION 3.18...4.0)

The upper-bound is typically the latest version of the CMake you have tested. For typical pip installs it's always the latest non-rc version. (It does not mean only up to CMake 4.0 can be used, it's just a setting to setup the backwards-compatibility behaviors)

CMAKE_BUILD_TYPE

scikit-build-pybind11-template/CMakeLists.txt

Lines 10 to 14 in 64e995f

	# Use Release builds by default for better performance
	if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
	set(CMAKE_BUILD_TYPE "Release" CACHE STRING "Build type" FORCE)
	set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
	endif()

This one should be moved before project (don't remember the reasoning tbh), but the logic there is generally superfluous. You can simplify it to:

set(CMAKE_BUILD_TYPE "Release" CACHE STRING "Build type")

CMAKE_EXPORT_COMPILE_COMMANDS is not useful

scikit-build-pybind11-template/CMakeLists.txt

Lines 16 to 17 in 64e995f

	# Enable faster incremental builds
	set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

This thing is only useful if you have a tool that it is reading it, and in those cases, the tools will generally inject it anyways.

ccache usage rant

scikit-build-pybind11-template/CMakeLists.txt

Lines 19 to 25 in 64e995f

	# Use ccache if available for faster rebuilds
	find_program(CCACHE_PROGRAM ccache)
	if(CCACHE_PROGRAM)
	set(CMAKE_CXX_COMPILER_LAUNCHER "${CCACHE_PROGRAM}")
	set(CMAKE_C_COMPILER_LAUNCHER "${CCACHE_PROGRAM}")
	message(STATUS "Using ccache: ${CCACHE_PROGRAM}")
	endif()

This makes it always be used if available, which might not be desired for users. Generally I would say let the user/dev/CI decide on what to use and inject the CMAKE_*_COMPILER_LAUNCHER needed. Another pattern is to gate it by an option()

Make use of generator expressions

E.g.:

scikit-build-pybind11-template/CMakeLists.txt

Lines 41 to 46 in 64e995f

	if(MSVC)
	# Windows: Enable parallel compilation and faster linking
	target_compile_options(hello_pybind11 PRIVATE
	/MP # Multi-processor compilation
	/bigobj # Large object files
	)

can be changed to

target_compile_options(hello_pybind11 PRIVATE
     $<$<CXX_COMPILER_ID:MSVC>:/MP>           # Multi-processor compilation
     $<$<CXX_COMPILER_ID:MSVC>:/bigobj>      # Large object files
)

Reference: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html

Compiler flags

Some are already provided by CMake itself, e.g.:

scikit-build-pybind11-template/CMakeLists.txt

Lines 57 to 58 in 64e995f

	$<$<CONFIG:Debug>:-g -O0>
	$<$<CONFIG:Release>:-O3 -DNDEBUG>

Is in the CMAKE_<LANG>_FLAGS_<CONFIG> cache variable

Please do not add -Wall to your projects by default. Put it in your CI, e.g. via CXXFLAGS environment variable or CMake presets. These are only meaningful to the developer, not the user/packager.

New way of specifying the linker tool

scikit-build-pybind11-template/CMakeLists.txt

Lines 64 to 66 in 64e995f

	if(LLD_PROGRAM)
	target_link_options(hello_pybind11 PRIVATE -fuse-ld=lld)
	endif()

I have not used it much, but it is now supported directly by CMake with CMAKE_<LANG>_COMPILER_LINKER. In gneral though, you should not hard-code it, because the user might not have lld actually, just the compiler, or they might want to use yet another linker.

Be careful how you handle RPATH

scikit-build-pybind11-template/CMakeLists.txt

Line 80 in 64e995f

INSTALL_RPATH_USE_LINK_PATH ON

RPATHs are very tricky subject to get it right, and for pyprojects, it is generally not what you want. Generally ignore these until you find that you actually need them. We do want to support them better out-of-the-box with scikit-build-core so that you don't need to manually define these, it would be better to keep an eye out on that feature and help us move forward with it.

Do not install directly in site-packages

This is a more scikit-build-core thing, but

scikit-build-pybind11-template/CMakeLists.txt

Lines 89 to 90 in 64e995f

	# Install target
	install(TARGETS hello_pybind11 DESTINATION .)

installs directly in site-packages, i.e. it installs site-packages/hello_pybind11.so. This is generally frowned upon because it can easily lead to file conflicts as the project grows. Instead you should have a site-packages/hello_pybind11/__init__.py and import submodules from there.

---

Overall though, it looks like a good start, these are mostly just nitpicks that I would like the community to adapt to as early as possible.

[brupelo]

Hi @LecrisUT — thanks a lot for such a detailed review, I really appreciate it! 🙏 I’ve incorporated your suggestions into this commit:
🔗 7e484b9 — feel free to take a look.

To avoid too much back-and-forth on PRs, I’ve added you with direct access to the repo. So if you spot any obvious antipatterns or improvements, please don’t hesitate to push directly to develop.

As I mentioned in the other thread, the goal of this project is to provide something the community can use out-of-the-box—no more worrying about boilerplate, bootstrapping, or juggling different tools. Just a modern, efficient, cross-platform setup for creating canonical C++/Python bindings.

Over the years, I’ve been through all sorts of setups—SWIG, Make, CMake, custom scripts, Meson—you name it (see this endless list: https://en.wikipedia.org/wiki/List_of_build_automation_software 😅). It’s been a huge time sink due to the lack of standardization.

Now, with tools like pyproject.toml, scikit-build, CMake, uv, just, and ninja, I feel we finally have a solid foundation to converge around. Sure, new tools will keep popping up, but having one proper, reliable way to build C++/Python extensions cross-platform would be a big step forward.

Just my 2¢ — maybe I’m too opinionated 😄

Thanks again!

[LecrisUT]

Glad it was useful.

Indeed these tools come-and-go, but often I find that the tools that develop the best are those that embrace the openness of FOSS and contribute all around.

There are various example projects scattered around that document how these tools interact with each other, e.g.:

• https://github.com/scikit-build/scikit-build-sample-projects
• https://github.com/scientific-python/cookie

I believe Henry has a better list of these, don't know if it got saved somewhere for quick reference. Of course I have one as well, and mine is mostly focusing on how to keep your CMake configuration clean for packagers and other people to be able to read it. Feel free to look into those for further inspiration.

It is always a good exercise to write your own example/template project as you learn the in-and-outs of each of these tools. All of them tend to converge on common practices eventually, and they do find a neiche topic that they develop in there. A recent one that people are working on is how to dynamically link between compiled python projects and be compatible with other environments packaging standards.

[brupelo]

Thanks!

I generally agree with you — and I love FOSS too ofc. What I’ve always found a bit troubling is that talented developers often prefer building new shiny things instead of investing effort in improving or streamlining existing old projects. That tendency often leads to fragmentation and a lack of standardization.

Btw, I noticed the use of noxfile.py in those repos—it's actually the first time I’ve come across it. In the past, I’ve worked extensively with tools like SCons and Waf, built custom CLI tooling using Typer and Click, and even developed a custom Python build system to replace make (did i mention fragmentation and reinventing the wheel :D?) , particularly focused on caching and efficient hashing of c++ content (wasn't necessary external tooling such as ccache, sscache, etc...). But at some point, I've hit roadblocks so i archived that one.

These days, I prefer something more data-driven / DSL, like [Just](https://github.com/casey/just), which feels like a modern take on good old make—though make itself isn't cross-platform. One of the persistent issues I've seen in the Python ecosystem over the past decades has been the lack of standardization in packaging and build tooling. The community is amazing, but this particular area has always been a pain—very similar to the C/C++ world.

Rust, on the other hand, got this right. Having a clear, unopinionated way to build and package projects avoids a lot of wasted time and money for everyone involved.

Anyway, thanks again for your help on this! I’m looking forward to seeing how this progresses. I’ve also been asking around in the Discord uv channel to gather more feedback. Hopefully, this little repo evolves into something useful to everyone—making it easier to focus on efficient development of complex C++ bindings without having to worry about packaging anymore.

[LecrisUT]

That tendency often leads to fragmentation and a lack of standardization.

Yeah, I know the feeling. What helped me get a more broader view is contributing to packaging and finding out how real-world projects are using them, what challenges they are facing, and eventually if they are pivoting towards one or another. It is how these things go, and now

But at some point, I've hit roadblocks so i archived that one.

Just to share that lots of us were/are there. You learn to not feel discouraged by these, and embrace the knowledge and experience you've picked up along the way. Time and project management can often be the limiting factor, but finding friends and community that are enthusiastic about the idea behind it, will help you come back to it.

About noxfile, it's meant to go beyond tox and have a python-aware way of handling scriplets. There are of course plenty of other standards, like hatch, uv. just sounds like a nice tool, but I would recommend to use a language-aware tools as much as possible. E.g. nox has built-in support for handling multiple python environments (though that is not used in scikit-build-core)

Rust, on the other hand, got this right. Having a clear, unopinionated way to build and package projects avoids a lot of wasted time and money for everyone involved.

There's plenty of duplication on the rust side as well 😉. Packaging rust crates for Fedora, we do help steer some of the projects away from un-maintained projects.

Anyway, thanks again for your help on this! I’m looking forward to seeing how this progresses. I’ve also been asking around in the Discord uv channel to gather more feedback

I'm not a heavy discord user, but pypa channel seems like a good place as well. I personally am most active on Fedora matrix channels.

[brupelo]

Really good advice, @LecrisUT, thanks! Personally, I’ve tried to open source a lot of cool projects over the years, but promoting them and getting people engaged — not just contributors, but truly involved participants — is tough. It often ends up with me doing most of the work myself, which is great in some ways. I love contributing to FOSS as much as I can, but given the sheer number of personal projects and ideas I have, it’s extremely difficult to balance everything.

What you’re saying makes a lot of sense — it’s about management, coordination, alignment, and making sure efforts are centralized around good initiatives. But that’s not easy. Just look at Python, PyPA, and the decades-long journey to reach stable standards like pyproject.toml. It took a lot of back and forth, ongoing discussions, and countless issues — like Python’s unlimited threads debate.

I’m not saying it’s easy, but don’t you think we could’ve reached this point faster? People often prefer creating shiny new things rather than reviewing standards, centralizing efforts, coordinating, and getting alignment. I include myself in that — I have projects where I reinvent the wheel, like my recent Python transpiler that leverages LLVM to generate standalone executables, instead of contributing to Numba or Codon. But at the end of the day, you do it because you enjoy taking the hard path. What can I say?

Anyway, I just pushed a new commit to this repo. It’s starting to become a bit more useful — updated to the latest uv version, no stale content, and I made the just pre-dev and just dev test recipes work properly, so you can do warm builds instead of cold builds like just clean bootstrap test.

Feel free to contribute directly and enhance best practices, post issues, suggest enhancements — whatever helps make this a solid initiative and effort. When you find active, friendly contributors like yourself, it’s always a pleasure to work on FOSS, but that’s not always the case.

Have a beautiful day!