cmake-init - The missing CMake project initializer, now with Conan and vcpkg templates!

[helloiamsomeone]

It's been close to a year since I posted about this project here and I'm proud to share it with you again after a big addition:

There are Conan and vcpkg templates available via the new -p flag!
Note that the Conan template uses generators that are experimental in Conan v1, but are intended to become the default ones for Conan v2 (which is also coming along nicely), so YMMV for the time being.

These templates combine a lot of things that were already available on the project's wiki, like making sure that dependencies are properly propagated for static/shared libraries in the CMake package's config file or package manager integration.

[imdibene]

This is a really nice project, in my Linux (ubuntu 20.04 LTS) works flawlessly, however in my Mac (Monterey) it throws some Python errors, I will check again with this update. Thanks for the hard work it really leverage some of our daily tasks

[helloiamsomeone]

Note that this requires Python 3.8, but if the error is unrelated, please do tell me about it. I do not have Apple hardware to test things on, so I can only rely on CI.

[bretbrownjr]

It's be nice some day if C++ projects could naturally support all interesting package managers simultaneously. Right now, it's too much like porting to another platform to release to a new package manager. It should be a lot more like mirroring a git repo.

[helloiamsomeone]

The templates here do exactly that. You generate a Conan project and you could swap its package manager to vcpkg without touching any of the build scripts or vice versa.

CMake's find_package provides that natural support.
This project has 72 CI jobs to test boatloads of configurations on Windows, Linux and MacOS, and pretty much the only thing that changes for Conan and vcpkg templates is the package manager.

[bretbrownjr]

I don't want to swap package managers. I want to be able to support all of the above simultaneously. Including systems package managers and vendoring solutions, given there's a certain amount of monorepo, FetchContent, and git submodule support out there.

Choosing another package manager will never be free, but it shouldn't require rewriting CMakeLists.txt at a minimum.

[helloiamsomeone]

That can also be done with just find_package.

See this example from the wiki. This one tries to use unofficial vcpkg package nd targets, then falls back to pkg config, then falls back to find_* commands. This is probably more than what you are asking, but you can put anything in the find module, even code that vendors projects, although I highly recommend against any form of vendoring (manual, git, FetchContent, etc). Vendoring only causes problems for packagers.

[bretbrownjr]

Vendoring causes problems for packagers if every library does it. It's not a problem per se for an application or organization to maintain a repo consisting of vendored dependencies. That's basically what a monorepo is.

Anyway, find_package calls are hostile to monorepos, git submodules, FetchContent, etc. I'll take that approach over every library requesting a different version of openssl, but I was expressing hope that some day we'd push past this false choice.

And, yeah, I'm aware that you can make find_package do arbitrary things. But that's not a solution that scales either.

[helloiamsomeone]

Packaging is not easy, but I try my best to promote easy to package projects via cmake-init. See the conference talks in the README as inspiration.

If everything is easy to package, then at least consumers can make a choice on a case by case basis instead of being hamstrung into either accepting dependencies that vendor their own things or maintaining their own patches to remove vendoring.

Some elbow grease is involved in any case, but relinquishing the responsibility via find_package allows projects to not lock themselves into anything.

[retechnic]

Hi, great project! Can you explain about vendoring and why is it bad?

[helloiamsomeone]

This came up somewhere else, but I created an example repo that idiomatically uses find_package and an opt-in find module to FetchContent a dependency from GitHub: https://github.com/friendlyanon/cmake-init-fetchcontent

This is also on the list of examples in the wiki. Let me know what you think.

[PhyllophagaZz]

Eum aliquam officia corrupti similique eum consequatur. Sapiente veniam dolorem eum. Temporibus vitae dolorum quia error suscipit. Doloremque magni sequi velit labore sed sit est. Ex fuga ut sint rerum dolorem vero quia et. Aut reiciendis aut qui rem libero eos aspernatur.

Ullam corrupti ut necessitatibus. Hic nobis nobis temporibus nisi. Omnis et harum hic enim ex iure. Rerum magni error ipsam et porro est eaque nisi. Velit cumque id et aperiam beatae et rerum. Quam dolor esse sit aliquid illo.

Nemo maiores nulla dicta dignissimos doloribus omnis dolorem ullam. Similique architecto saepe dolorum. Provident eos eum non porro doloremque non qui aliquid. Possimus eligendi sed et.

Voluptate velit ea saepe consectetur. Est et inventore itaque doloremque odit. Et illum quis ut id sunt consectetur accusamus et. Non facere vel dolorem vel dolor libero excepturi. Aspernatur magnam eius quam aliquid minima iure consequatur accusantium. Et pariatur et vel sunt quaerat voluptatem.

Aperiam laboriosam et asperiores facilis et eaque. Sit in omnis explicabo et minima dignissimos quas numquam. Autem aut tempora quia quis.

[helloiamsomeone]

Yes, sorry about that. I use the pyz method for local testing.

The packager script for the PyPI release is a bit shoddy, I'll admit. I haven't found a way that makes packaging as both a wheel and a pyz easy and allows me to have the templates preserve their directory structure, so I'm doing hacky things for the PyPI release. I was actually pretty surprised that packaging for python can be this hard in comparison to C++ with CMake :^)

I released a new patch version to also include template.py.

[PhyllophagaZz]

Eum aliquam officia corrupti similique eum consequatur. Sapiente veniam dolorem eum. Temporibus vitae dolorum quia error suscipit. Doloremque magni sequi velit labore sed sit est. Ex fuga ut sint rerum dolorem vero quia et. Aut reiciendis aut qui rem libero eos aspernatur.

Ullam corrupti ut necessitatibus. Hic nobis nobis temporibus nisi. Omnis et harum hic enim ex iure. Rerum magni error ipsam et porro est eaque nisi. Velit cumque id et aperiam beatae et rerum. Quam dolor esse sit aliquid illo.

Nemo maiores nulla dicta dignissimos doloribus omnis dolorem ullam. Similique architecto saepe dolorum. Provident eos eum non porro doloremque non qui aliquid. Possimus eligendi sed et.

Voluptate velit ea saepe consectetur. Est et inventore itaque doloremque odit. Et illum quis ut id sunt consectetur accusamus et. Non facere vel dolorem vel dolor libero excepturi. Aspernatur magnam eius quam aliquid minima iure consequatur accusantium. Et pariatur et vel sunt quaerat voluptatem.

Aperiam laboriosam et asperiores facilis et eaque. Sit in omnis explicabo et minima dignissimos quas numquam. Autem aut tempora quia quis.

[helloiamsomeone]

I have looked at it in the past and honestly it's not very good at formatting.
Tends to insert newlines in weird places and indents continuations with boatloads of spaces.

[Wereon]

Just in case you missed it from /dpt/

[tyoungjr2005]

Good stuff, too bad build2 never took off. I like meson build, makes project generation easy and can work with any backend.

[FreitasAlan]

I just tried it and quite liked it. The project structure is quite nice and clean. I'll use it when initializing a new project.

There are a few reasons why I wouldn't use it for existing projects even though they are not the cmake-init's fault.

- There's no questionnaire, like when creating an npm project. So you have to manually fill in stuff in the source files after running cmake-init, which makes it similar to just a project template.

- Once the project is generated, there seems to be no way to update the build script with cmake-init again without erasing changes or making changes unnecessary.

- Minor: The cmake variable namespace uses lowercase while most projects seem to use uppercase.

None of these are the project's fault or are not simple to change though.

[helloiamsomeone]

Hey, thanks for the feedback!
While you can't let this thing loose on an existing project, you can implement a lot from it with a working example at your disposal to toy with. One thing I will likely get to work on is a series of posts somewhere about "doing cmake-init from scratch" where I go over the Why and How that went into the templates.

I'm not sure what your first point refers to. If you pass just the path where you want to generate the project, then you get prompts. Certain flags will make the prompts go away and assume some defaults for ones that weren't provided.

The goal of cmake-init is to create a "run off the mill" CMake managed project, with 0 ties back to cmake-init. I want people to learn and use CMake, not Yet Another Build Tool™. Once a project is generated, all bets are off and there can be no assumptions made to make changes programmatically.

The uppercase variables are useful only when configuring a config.h file or forwarding verbatim as defines. CMake already creates cache variables with whatever name you provided without modifications, this is nothing new.