Qt Creator w/CMake: Multi-config Build Configuration?

[oblivioncth]

To start, I'm using Qt 6.2.3 with Qt Creator 6, CMake 3.21.1, and the Ninja Multi-config Generator.

It seems that what I want to accomplish is already a little bit of a mess even when running cmake directly from the command line due to some temporarily canceled features, but does seem to be possible; however, I'm not sure I can do this from within Qt Creator, which I would like to do so that I don't have to handle the massive amount of variable setting and other configuration that Qt Creator preforms based on my Kit settings when setting up a CMake build (unless someone can tell me an easy way to "export" or otherwise replicate the environment that Qt Creator provides to CMake as it seems a bit more involved than it was with qmake).

Is there someway I can setup a build configuration so that when I click build the following happens?:

• All targets with the Debug configuration are built and installed
• All targets with the Release configuration are built and installed
• CPack is run with the -C switch specifying "Debug;Release"

Running CPack is easy, its just a custom build step. The issue here is that the build configurations of Qt Creator seem to be directly tied to, well... the build configurations of the loaded project (which is reasonable), but I think that inadvertently makes this impossible since "Build Type" must be specified and Creator uses that value for the --config switch in a manner that seems to not be able to be changed.

I'd imagine I'd want something like:

cmake.exe --build <build_path> --target all install --config Debug
cmake.exe --build <build_path> --target all install --config Release
cpack.exe -C Debug;Release {other options...}

but again you can't change the --config parameter. I suppose I could try forcing it by using Custom Process Steps and adding the arguments myself, but the less hacky the solution is the better.

In theory this super straight forward as a batch/shell script, but like I said it wouldn't actually be just those three lines, I'd have to make sure to set the dozens of environment variables the same way Qt Creator does, including setting CMAKE_FIND_ROOT_PATH for Qt6, and then ideally do so using a INI file or the like so that the script itself is system agnostic. At the moment I'd rather not be responsible for all of that since I just finished porting my first medium sized project to CMake, even though I'll get there eventually.

[Christian Ehrlicher]

Github should be able to do it for you. See e.g. https://resources.github.com/ci-cd/

[oblivioncth]

Well I'm open to a less hacky and more efficient solution but the following seems to work:

1. Ensure a multi-config generator is being used (in my case Ninja Multi-Config)
2. Clone the default Release configuration to one with a reasonable name (e.g. Full Package)
3. Tick off the 'install' target of the default Build step
4. Add a custom process step below the default Build step with the following info:

Command: cmake.exe
Arguments: --build "%{buildDir}" --target all install --config Debug 
Working directory: %{buildDir}

5. Add another custom process step below the previous with the following info:

Command: cpack.exe
Arguments: -C Debug;Release [OTHER CPACK OPTIONS HERE]
Working directory: %{buildDir}

6. Run the build

As long as your CMake scripts are setup to handle build, install, and CPack configuration properly, this will result in the Debug & Release configuration being built and installed, followed by the artifacts of both being packaged with CPack.

CMake automatically handles target exports of Debug vs. Release elegantly so simply having a static install directory that doesn't change depending on Debug/Release so that their outputs get merged will work, unless you have other custom differences between Debug/Release configs that would cause a non-CMake generated filename conflict.

[Christian Ehrlicher]

IMO this is normally a task for a CI system.

[oblivioncth]

@Christian-Ehrlicher

I've always been very interested in them and have interacted with them indirectly, like with contributions to Qt, but I figured that such a system only made sense in such large scale applications and would be crazy overkill for building and packing small to medium sized, very niche FOSS. Generally I only need builds for Windows and to a lesser extent Debian as well .

Do more simple/small-scale CI exist? At the very least I'll look out of curiosity.

[Christian Ehrlicher]

Github should be able to do it for you. See e.g. https://resources.github.com/ci-cd/

[oblivioncth]

@Christian-Ehrlicher

Wow, you learn something new every day.

I never knew that GitHub Actions were this powerful and had this much variety, let alone free (for public repos)! I always thought that the results of these features I've come across on some repos that suggested the existence of such functionality were just due to a lot of manual setup and integrations with third-party services.

Overall, I still think this is a tad overkill for what I need, but at the same time with in enough realm of reason that I think this is a good excuse to get my feet wet and get used to leveraging CI in general, even if it takes me a while.

I have a ESXi server that more recently has been under-used, so it would be perfect for spinning some up some runners.

Thanks!

[Christian Ehrlicher]

For the time beeing a simple bat / bash script should help in your case to build and deploy everything. But it's not callable from inside QtCreator though.

[oblivioncth]

@Christian-Ehrlicher

Yea, that certainly would work. I just wanted to avoid dealing with handling all of the environment setup with CMake and the build tools that QtCreator does for you transparently (which I would then need to modify on each different system I build on in addition to the different settings of QtCreator on said systems, so there's a little redundancy), but in the end its not too many variables so if I can't get anything setup CI-wise for a while and run into issues with the above jank then I'll just make a script.

[oblivioncth]

@Christian-Ehrlicher Just wanted to thank you for letting me know about this.

It took a while to learn some of the finer details, get everything setup, and debug, but in addition to porting my first project to Qt 6 and CMake, it's now also my first project using GitHub actions!

https://github.com/oblivioncth/Qx

It's really nice to have automated builds, checks, releases, and publishing of doxygen pages. Definitely worth the upfront work, especially since it will be way easier doing this for other repositories now that I know what I'm doing.