I am quite a new user of cmake, but I have pretty good experience with gradle and maven.
When googling around for cmake capabilities, most resources I find are focused on fulfilling different aspects of building source for target.
I am interested in using CMake to also run other project tasks such as for instance
automatically sync with a git fork upstream repository
post a release page via a REST api
provide user with information (i.e. run tasks similar to ‘git status’ that only produces feedback to the user but no build output/side effects)
produce all kinds of non-code resources such as archive files, producing documentation pdfs
determine a build-id via git history (based on tags and revision history, similar to git describe)
automate setup of hardware interaction (i am working with embedded software, so there are numerous of possible tasks related to connecting, uploading running on target that would be nice to automate.)
So far I’ve understood that it seems possible to do all or most of these things with CMake, although it does not seem like an ordinary use case.
My question is this:
Is cmake a good fit for creating automation support similar to what i mentioned above, or should I let cmake focus only on building? If cmake is a good fit, what approach of implementation would be 'best practice"?
(also, I’m thankful for all/any tips on resources where I could learn how to do the above mentioned things)
I wouldn’t recommend CMake for syncing with Git - that’s what Git is for
I haven’t heard of anyone using CMake to post release pages or interact with hardware, though I suppose you could use custom targets for this.
Provide user with information - again, custom targets are good for this.
The build for CMake itself produces non-code artifacts like documentation and resources, so this is a good fit. Same for determining build-id via Git history.
I totally agree that git should be managed with git
my use case for interacting with git would be specific, often reoccuring, tasks. for instance, currently we have a forked repository that cannot be automatically synced with the upstream repository, so there is a pipeline on our build server that keeps them in sync (as a means of reusing code within our company). the pipeline runs two bash scripts, but my idea would be to sort of migrate such scripts into custom targets in cmake. in other words, to sort of wrap some multistep git operations into a custom target in cmake.
In my head, the upside would be that:
it is more userfriendly to have a single workhorse for task execution, instead of a bunch of scripts
a custom target can be integrated in say a release build, to ensure that things are up-to-date
depending on how it is migrated to cmake, I wish that maybe it could be made more portable
but I take it that your suggestion is to go along the line of custom commands and custom targets?
Yes, that’s the only mechanism CMake provides for tasks other than building source files for adding things to the build graph. I’d recommend writing them as CMake scripts and then triggering them from custom targets myself, but there are other ways to do it too (shell scripts, custom Makefile somewhere, etc.).
Another possible mechanism I use is using ctest as a front end with a targetless cmake project project(tester LANGUAGES NONE). For example as part of a test suite I need to download something and run tests, but if that download fails then disable certain tests. Use ctest labels and regex to run complex subsets of tests that will be skipped or disabled if one of the tests fails.
One of the techniques I use in this pattern is having add_test(COMMAND ${CMAKE_COMMAND} -P my.cmake) calling little CMake script snippets that download or extract files.
One could use bash or python to do the same thing, but I needed it to be cross-platform and in my milieu there are few, yet too many non-sudo access systems that have broken Python installs. And the users didn’t want to bother to install Python, and already have CMake.
