Qt Creator 2.3 and Remote Linux Deploy
Once again, the news went unnoticed on Habré, which ran through Qt Labs blog and announced Qt Creator 2.3. If you briefly review the list of changes, then as usual you can see a bunch of cool buns, one of which interested me incredibly. Namely, the deployment and debugging of an application on a remote Linux machine, using ssh, directly from the development environment.
Why was this interesting to me? Yes, because:
1) We have an arm-piece of iron in the office, for which our own Qt / Embedded + Linux based firmware is being sawn.
2) Cross-compilation, deployment and debugging of the regular version of any of the programs written using Qt, as it is not difficult to guess delivers incredible pleasure and sexual satisfaction in view of the need to use
a bunch of self-made scripts such as build.sh, deploy.sh, and so on.
3) Efficiency decreases (but the level of irritation increases) and I even began to dig into the sources of the android-lighthouse in order to steal the method of deploying packages to a virtual Android phone from there ... Thank God I didn't have time to write anything)
What is offered to us? As it is known before, Qt Creator already had tools for deploying Symbian applications (via USB-MicroUSB) and for Maemo (via ssh). Apparently in this version, the developers decided to bring the idea to mind, and due to the unification of the Maemo deployment tool, it was possible to allow applications to be deployed on ordinary Linux machines.
We have a couple of new tabs in the settings:
Go?
')
Initial conditions:
The main Linux machine, on which the Qt Creator 2.3 Beta development environment is installed, is gdb and contains the source code of the required program.
Remote Linux device, ssh access and gdbserver installed.
Cross-toolchain for build (with compiled Qt / Embedded of course) and cross-compiler. Which, for example, as in my case, are never on the same machine as the source, but even on a nearby server). That the task doesn’t make it easier ... But I will nevertheless explain it with this example. Buildroot is used as a toolkit, codesourcery is used as a set of compilers. Platform - ARM (armv7a).
So, the first thing to do is ask qmake for the cross-compiled version of Qt about something ... Namely, go to the machine where we have the cross-build tools and do something like this:
It kind of hints at the location of our library. Just in case, look into the file
To make sure that the toolchain there is indicated quite correct:
The next stage of preliminary preparation is to mount all the necessary directories on sshfs so that it would seem to the toolchain and others that they were not mounted anywhere, but they live quite happily on the same machine where they should be. It is easy to guess, you have to mount 2 directories: / root / codesourcery / and / root / openaos / br11_glibc_building /
We do ...
Yes, I know, of course, it’s a little ugly to give such rights to the rutovy catalog and generally looks bony ... But what to do when they deployed all this assembly garbage, there was little experience and time ... And on a virtual machine, why not use the root?
And nevertheless, we will continue. In fact, at the moment, the assembly tools are already available on our host machine, and if you do something like ls / root / openaos / br11_glibc_building / output / staging / usr / lib , you can get not a message about the missing directory, but quite adequate, though and the inhibited reaction of ls outputting hundreds of files. Sometimes it even seems, why the hell is all this necessary ... =)
Okay. Run the creator and go to settings. First of all, it is worth pointing the way to the newly-minted Qt (something habrastorage died at this moment that put me in a stupor, but where ours did not disappear ...):
From the picture it is clear that the development environment found the library itself and other garbage, but was very upset that it did not know what to compile all this and where to get the toolchain. Let's explain ...
To do this, go to the “Tools” section, add a new GCC compiler, and fill in the required fields - the path to the compiler and debugger:
Again we return to the Qt section and voila, the messages about the missing toolchain are gone:
The final touch in the settings dialog is to add the device on which we want to deploy our application ... there is nothing easier, go to the Linux Devices section, click the button “Add” -> “Generic Linux Device” -> fill in the wizard fields and complete the setting . A window with a connection test will appear immediately.
What is remarkable, if you don’t want to have a password on a remote machine, you can immediately generate a pair of ssh keys from the connection settings interface and even secure the public key to the device. And then it is easy to remove the password or forget the password ... True, one bug is still present here. The public key will be recorded in <user directory> /. Ssh / authorized_keys and therefore key authorization will work if a full ssh server is installed on the device, and not some dropbear for example. It is also worth paying attention to the “Device Type” item, which suggests that nothing prevents us from running our remote Linux on a virtual machine. Although of course this was so clear ...
Click OK and close the settings dialog. Is that all? FIG =)
Open the project related to the piece of iron, go to the “Projects” tab and change the configuration of the assembly to the one we need.
As you can see, when the configuration was changed, the required Qt version and the required toolchain were automatically selected. The truth is that there is still a second bug waiting for us - whatever Qt profile is selected, the default parameter -spec will still be equal to linux-g ++. and we need "-spec qws / linux-arm-g ++", which can be corrected by entering it in the "Additional parameters" field of the qmake build phase. If you do not do this, of course, there will be a lot of terrible mistakes:
In the launch settings, you also need to make changes - add a new configuration “Build Tarball and Install to Linux Host”, in the window that appears, select the necessary subprojects that you would like to add, agree, and go through the list of files to install and if you need to change something ... By the way , if you want to change the installation paths of some files, then everything is configured in the project file with directives like:
Further, just below we add a new version of the application launch - “binary_name (remote)”, add a parameter to the example “-qws”, since this is an application for the Embedded version of the library. It turns out something like:
Already not bad ... What's next? Next - try to collect! Editor -> Build (Esc -> Ctrl + R). And wait until our application is assembled. In my case, this is the longest procedure ...
Drank coffee? Now look at your piece of iron ... Has your application window appeared there? If everything was all right, then it should have ...
That's just ... If in your project, in addition to the applications themselves, there are also shared libraries, then at the stage of building the tar-archive to fill it on the device, an error like this may appear:
This is of course easy to fix, but still not very nice to receive similar error messages at the very end of the application build. We'll have to do something like for all shared libraries included in the project:
Finally, after the final fixes, you can see the final log of the development environment, which already shouts its readiness:
And the application launch log screaming happily:
Actually ... This method of deploying applications can be used not only for cross-assembling or remote start, but also simply for automatically assembling tar-archives with distributions of your applications. To do this, it is enough to specify the host machine IP scan as a machine and insert the necessary installation instructions into the .pro file. This increases the ease of development, for example, QML applications, in which there are always a bunch of small files that need to be dragged along on their heels ... And so, you can finally not make a fuss and use the same INSTALL parameters from the .pro file to build distributions for linux , which are also used when building distributions for Symbian.
Here is a feature that once again shows that:
a) software development can be simple
b) Qt developers think first of all about their users (that is, developers who use their product) and do everything to increase their productivity and attractiveness of the library as a whole.
Thank you, I hope someone will be useful.
Why was this interesting to me? Yes, because:
1) We have an arm-piece of iron in the office, for which our own Qt / Embedded + Linux based firmware is being sawn.
2) Cross-compilation, deployment and debugging of the regular version of any of the programs written using Qt, as it is not difficult to guess delivers incredible pleasure and sexual satisfaction in view of the need to use
a bunch of self-made scripts such as build.sh, deploy.sh, and so on.
3) Efficiency decreases (but the level of irritation increases) and I even began to dig into the sources of the android-lighthouse in order to steal the method of deploying packages to a virtual Android phone from there ... Thank God I didn't have time to write anything)
What is offered to us? As it is known before, Qt Creator already had tools for deploying Symbian applications (via USB-MicroUSB) and for Maemo (via ssh). Apparently in this version, the developers decided to bring the idea to mind, and due to the unification of the Maemo deployment tool, it was possible to allow applications to be deployed on ordinary Linux machines.
We have a couple of new tabs in the settings:
- Instructions - here you can specify the compiler. Of course, both simple and cross-compiler.
- Linux Devices - here you can see the configuration settings of the assembled application on the remote machine
Go?
')
Initial conditions:
The main Linux machine, on which the Qt Creator 2.3 Beta development environment is installed, is gdb and contains the source code of the required program.
Remote Linux device, ssh access and gdbserver installed.
Cross-toolchain for build (with compiled Qt / Embedded of course) and cross-compiler. Which, for example, as in my case, are never on the same machine as the source, but even on a nearby server). That the task doesn’t make it easier ... But I will nevertheless explain it with this example. Buildroot is used as a toolkit, codesourcery is used as a set of compilers. Platform - ARM (armv7a).
So, the first thing to do is ask qmake for the cross-compiled version of Qt about something ... Namely, go to the machine where we have the cross-build tools and do something like this:
# /root/openaos/br11_glibc_building/output/staging/usr/bin/qmake -v QMake version 2.01a Using Qt version 4.7.1 in /root/openaos/br11_glibc_building/output/staging/usr/lib It kind of hints at the location of our library. Just in case, look into the file
/root/openaos/br11_glibc_building/output/staging/usr/mkspecs/qws/linux-arm-g++/qmake.conf To make sure that the toolchain there is indicated quite correct:
QMAKE_LFLAGS = -L/root/openaos/br11_glibc_building/output/staging/lib -L/root/openaos/br11_glibc_building/output/staging/usr/lib QMAKE_CXXFLAGS = --sysroot=/root/openaos/br11_glibc_building/output/staging -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Os -mtune=cortex-a8 -march=armv7-a -mab$ QMAKE_CFLAGS = --sysroot=/root/openaos/br11_glibc_building/output/staging -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Os -mtune=cortex-a8 -march=armv7-a -mabi=$ QMAKE_STRIP = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-strip QMAKE_RANLIB = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-ranlib QMAKE_OBJCOPY = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-objcopy QMAKE_AR = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-ar cqs QMAKE_LINK_SHLIB = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-g++ --sysroot=/root/openaos/br11_glibc_building/output/staging QMAKE_LINK = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-g++ --sysroot=/root/openaos/br11_glibc_building/output/staging QMAKE_CXX = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-g++ QMAKE_CC = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-gcc The next stage of preliminary preparation is to mount all the necessary directories on sshfs so that it would seem to the toolchain and others that they were not mounted anywhere, but they live quite happily on the same machine where they should be. It is easy to guess, you have to mount 2 directories: / root / codesourcery / and / root / openaos / br11_glibc_building /
We do ...
$ sudo chmod 777 /root $ cd /root $ mkdir oabroot $ sshfs root@openaos-build.lan.arta.kz:/ oabroot/ $ ln -s oabroot/root/openaos/ ./ $ ln -s oabroot/root/codesourcery/ ./ $ ls -l 4 lrwxrwxrwx 1 kafeg kafeg 26 2011-07-22 16:10 codesourcery -> oabroot/root/codesourcery/ drwxr-xr-x 1 root root 4096 2011-07-13 08:44 oabroot lrwxrwxrwx 1 kafeg kafeg 21 2011-07-22 16:10 openaos -> oabroot/root/openaos/ Yes, I know, of course, it’s a little ugly to give such rights to the rutovy catalog and generally looks bony ... But what to do when they deployed all this assembly garbage, there was little experience and time ... And on a virtual machine, why not use the root?
And nevertheless, we will continue. In fact, at the moment, the assembly tools are already available on our host machine, and if you do something like ls / root / openaos / br11_glibc_building / output / staging / usr / lib , you can get not a message about the missing directory, but quite adequate, though and the inhibited reaction of ls outputting hundreds of files. Sometimes it even seems, why the hell is all this necessary ... =)
Okay. Run the creator and go to settings. First of all, it is worth pointing the way to the newly-minted Qt (something habrastorage died at this moment that put me in a stupor, but where ours did not disappear ...):
From the picture it is clear that the development environment found the library itself and other garbage, but was very upset that it did not know what to compile all this and where to get the toolchain. Let's explain ...
To do this, go to the “Tools” section, add a new GCC compiler, and fill in the required fields - the path to the compiler and debugger:
Again we return to the Qt section and voila, the messages about the missing toolchain are gone:
The final touch in the settings dialog is to add the device on which we want to deploy our application ... there is nothing easier, go to the Linux Devices section, click the button “Add” -> “Generic Linux Device” -> fill in the wizard fields and complete the setting . A window with a connection test will appear immediately.
What is remarkable, if you don’t want to have a password on a remote machine, you can immediately generate a pair of ssh keys from the connection settings interface and even secure the public key to the device. And then it is easy to remove the password or forget the password ... True, one bug is still present here. The public key will be recorded in <user directory> /. Ssh / authorized_keys and therefore key authorization will work if a full ssh server is installed on the device, and not some dropbear for example. It is also worth paying attention to the “Device Type” item, which suggests that nothing prevents us from running our remote Linux on a virtual machine. Although of course this was so clear ...
Click OK and close the settings dialog. Is that all? FIG =)
Open the project related to the piece of iron, go to the “Projects” tab and change the configuration of the assembly to the one we need.
As you can see, when the configuration was changed, the required Qt version and the required toolchain were automatically selected. The truth is that there is still a second bug waiting for us - whatever Qt profile is selected, the default parameter -spec will still be equal to linux-g ++. and we need "-spec qws / linux-arm-g ++", which can be corrected by entering it in the "Additional parameters" field of the qmake build phase. If you do not do this, of course, there will be a lot of terrible mistakes:
... qatomic_arm.h:131: Error: no such instruction: `swpb %dl,%al,[%ebx]' ... In the launch settings, you also need to make changes - add a new configuration “Build Tarball and Install to Linux Host”, in the window that appears, select the necessary subprojects that you would like to add, agree, and go through the list of files to install and if you need to change something ... By the way , if you want to change the installation paths of some files, then everything is configured in the project file with directives like:
unix:!symbian:!maemo5:isEmpty(MEEGO_VERSION_MAJOR) { target.path = /opt/authorize/bin INSTALLS += target } Further, just below we add a new version of the application launch - “binary_name (remote)”, add a parameter to the example “-qws”, since this is an application for the Embedded version of the library. It turns out something like:
Already not bad ... What's next? Next - try to collect! Editor -> Build (Esc -> Ctrl + R). And wait until our application is assembled. In my case, this is the longest procedure ...
Drank coffee? Now look at your piece of iron ... Has your application window appeared there? If everything was all right, then it should have ...
That's just ... If in your project, in addition to the applications themselves, there are also shared libraries, then at the stage of building the tar-archive to fill it on the device, an error like this may appear:
Creating package file ... Error reading file '/root/oabroot/*/libqmlgestureareaplugin.so.1': No such file or directory. artagui (: Desktop) «Create tarball» This is of course easy to fix, but still not very nice to receive similar error messages at the very end of the application build. We'll have to do something like for all shared libraries included in the project:
$ ln -s /root/oabroot/*/libqmlgestureareaplugin.so /root/oabroot/*/libqmlgestureareaplugin.so.1 $ ln -s /root/oabroot/*/libqmlgestureareaplugin.so /root/oabroot/*/libqmlgestureareaplugin.so.1.0 $ ln -s /root/oabroot/*/libqmlgestureareaplugin.so /root/oabroot/*/libqmlgestureareaplugin.so.1.0.0 Finally, after the final fixes, you can see the final log of the development environment, which already shouts its readiness:
And the application launch log screaming happily:
Killing remote process(es)... Starting remote process ... Remote process started. Killing remote process(es)... Actually ... This method of deploying applications can be used not only for cross-assembling or remote start, but also simply for automatically assembling tar-archives with distributions of your applications. To do this, it is enough to specify the host machine IP scan as a machine and insert the necessary installation instructions into the .pro file. This increases the ease of development, for example, QML applications, in which there are always a bunch of small files that need to be dragged along on their heels ... And so, you can finally not make a fuss and use the same INSTALL parameters from the .pro file to build distributions for linux , which are also used when building distributions for Symbian.
Here is a feature that once again shows that:
a) software development can be simple
b) Qt developers think first of all about their users (that is, developers who use their product) and do everything to increase their productivity and attractiveness of the library as a whole.
Thank you, I hope someone will be useful.
Source: https://habr.com/ru/post/124695/
All Articles