[Qt-creator] Making CMake and Remote Linux work together

Oleksii Serdiuk contacts at oleksii.name
Tue Jul 9 19:13:38 CEST 2013


Hi everybody,

First, a short background. At my work we're developing for Linux powered
terminals and using CMake as a build system. Till recently, development
and debugging was done on developers' machines, but now we came to the
stage, when we need to be able to deploy and remotely debug on the
actual device. Remote Linux plugin functionality is perfectly enough for
this. But to my big surprise, when I created remote Linux target I was
still presented with local deployment and run options. So I dived into
CMake plugin source and found out that, for some unknown reason, it
deliberately limits itself to Desktop targets. I was able to make it
work with Remote Linux plugin pretty easily, but there were two
limitations I needed to overcome. I submitted my changes to Gerrit and
few concerns were raised there, so I'm writing to this list to discuss
them.


1. https://codereview.qt-project.org/60679

Remote Linux plugin uses Target::deploymentData() to get a list of files
to be deployed. CMake didn't set this value. As far as I understood
current CMake plugin implementation, it runs CMake to generate Code
Blocks project (which is an XML file) and then extracts targets and
build commands from it. While it's possible to extract libraries and
executables by traversing through build targets, I didn't find a way to
specify a list of additional files to be deployed (i.e., resources, QML
files, etc.). Also, there is no way to specify deployment prefix on the
remote machine.

My solution to this problem was to create a text file
CMakeDeployment.txt which contains deployment prefix and a list of
arbitrary files to deploy. This file can be easily created automatically
by defining and using CMake macros (I made one which I can share).

Another approach, which was also suggested by Daniel Teske in code
review comments, is trying to use CPack for this. However, I didn't find
a way to just get a list of files from CPack and creating a full archive
just to get a list of files from it seems a bit of overkill for me.
Especially, if files to be deployed are quite big. Also, AFAIU, CPack
can be run only after building, which means deployment files can be
populated only after successful build.


2. https://codereview.qt-project.org/60674

A second issue is with deploying binaries extracted from build targets.
CMake plugin creates a separate binary target for every executable and
library that will be built, but uses "all" target for building. Also,
you can exclude some targets from being build by "all". Unfortunately,
there is no dependency information available in the plugin (and also in
the Code Blocks file it generates) so it's not possible to know which
targets will be built by issuing "make all". This means that if you put
all binary targets into the deployment list and at least one of them was
excluded from "all", the deployment will fail due to non existing file
(it just wasn't built).

I overcame this limitation by adding a way to specify whether
DeployableFile is enabled (DeployableFile::isEnabled() and
DeployableFile::setEnabled() members) and adding checkboxes to "Files to
deploy" list. User can uncheck the specific file and it won't be
deployed by the Remote Linux plugin. But Christian Kandeler said that he
doesn't like this concept because build system should take care of such
things.

Alternative to this solution might be adding a possibility to mark files
as non-critical for deployment so that when deployment of these files
fails, only a warning is issued and deployment continues.


I'd like to discuss possible alternatives to these solutions or whether
they are good enough for now.

-- 
With best regards,
Olekii Serdiuk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20130709/a2abcfca/attachment.bin>


More information about the Qt-creator mailing list