cookie-cutter project

[LecrisUT]

I don't know if this is present in a different project, but it would be nice to have a cookie-cutter project to highlight:

• Modern CMake project design
• Modern CI tools for Python and C++
• Incorporate bindings with Swig or other language specific ones like pybind, including packaging via skbuild-core
• Tools for downstream packaging and testing

In designing and modernizing some CMake projects, I've found quite a few hidden gems that are available in CMake like FeatureSummary, the interplay between FetchContent and find_package, etc. and I want to share them in a more accessible location. Do you think we can host this here or in a different organization?

I'm not familiar with cookie-cutter engines, and I think that could clash with having a plain repo that people can navigate and learn through the documentations and comments. If you know of a good example that have a balanced of these let me know.

[henryiii]

I'd recommend first looking at https://github.com/scientific-python/cookie (cookiecutter and copier supported), as well as https://github.com/pybind/scikit_build_example (plain repo). Yes, it's not great navigating a cookiecutter repo directly. It could possibly be rendered into documentation (that's partially done for scientific-python/cookie, some of the code blocks are rendered from the cookie).

I don't really want to maintain two cookiecutters (especially at the scale of scientific-python/cookie, which is a guide + cookie with 10+ backends + repo-review plugin, included via WebAssembly in the guide) until it's necessary. What I was thinking is that maybe skbuild new could provide this sort of setup. If that doesn't work / is too much work, having a cookiecutter that only produces scikit-build projects, but has options for which binding tool to use, etc. is something we should eventually add.

[henryiii]

I'm also pushing for better "on" support in cookiecutter - if that makes it in, then having conditional questions would be feasible. Harder to test, but easier to add multiple binding tools only if a compiled backend was selected, for example.

Also see https://cliutils.gitlab.io/modern-cmake, my book on Modern CMake.

[LecrisUT]

What I was thinking is that maybe skbuild new could provide this sort of setup.

Do we include CI tools in there as well? I was thinking for that we only focus on cmake + skbuild-core, and we could reference to a template project otherwise for more details on CI tools and everything.

Also see https://cliutils.gitlab.io/modern-cmake, my book on Modern CMake.

Good book, I might quote it some times for quick reference ;). I have some notes on some other paradigms that I want to share, but it would be clearer in an example repo.

For now, how about if I make a plain repo to first show-case some of the topics I want to highlight.

[henryiii]

Sure, feel free to make something and we can look at it.

[LecrisUT]

Still working on it, but the WIP is in LecrisUT/CMake-Template#1. There are quite a few comments there, mostly to point out some of the topics to present for the cookie-cutter project and as reminder to add them to the proper documentation about it.

[LecrisUT]

Btw, I've added documentation to my template project, but could always use more comments and discussion on the ideas in there. My plan is to keep that template as bare-bones like that with just the minimum for a modern CMake project, and then have daughter templates, e.g. python interface, which links back to the base template for the common documentation and builds up on the specific topic. Thoughts?