Upgrading Quickbar from SFOS 3 to SFOS 5 #2

 

Yesterday we "rebooted"  the source repository, and tried to build Quickbar with the SFOSSDK.  Turns out I forgot that the SDK itself was outdated. (SFOS4 to be exact). So well, the next best thing, of course, is to update the SDK. Firing up the maintenance tool, updating it and then update the SDK was a breeze. I believe between version 4 and 5, Jolla changed ownership (from ROSTELECOM to Jollyboys). The SDK has survived this exceptionally well it seems kudos to Jolla, in comparison to what Harmattan experience was like, this is a thousand times better. 

However, the issue is not solved with the update. So more digging appears to be in order. Taking a closer look at the compiler's build steps (from the "Compiler output" window), we see the building command via sfsdk : 

<sdk_install_path>/SailfishOS/bin/sfdk qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

it appears to be correct, referencing the right .pro file (debota-sailfish.pro; "debota" is Retoromanic for "fast" in case you were wondering). However, even tho the parameter is correct, down the line, we can see that the real make command:

 /usr/bin/qmake -qt=5 -makefile <lot of stuff we do not care about>  LIBDIR=/usr/lib64 /home/tone/checkouts/svn/debota -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

appears to be _missing_ the .pro entry. Remember, this issue carried over from SDK Version 3. It's quite interesting to see the behavior has survived. We could cludge this by removing the extra .pro files. But let's see if we can spot what eats the debota-sailfish.pro 

The command before that is (a long one, but we need that to highlight that the .pro file is missing here as well):

qmake -qt=5 -makefile 'QMAKE_CFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' QMAKE_STRIP=: PREFIX=/usr LIBDIR=/usr/lib64
 

I would assume a similar behaviour to be spotted by others among the community. So this is either a known bug with really low priority (for whatever reason), or then its a design choice. Let's see if we can clear this up!

So as a first step (after starting the building engine), QtCreator launches:

$HOME/.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default/qmake" /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug 

which is correct and coherent to what we get from the "Projects" section in QtCreator:

$HOME.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default/qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

so QtCreator is off the hook. Let's descend one layer...by adding a set -x to the script file in 

$HOME/.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default/qmak 

we can get more info:

+ ARGUMENTS=
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++' 'CONFIG+=debug'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++' 'CONFIG+=debug' 'CONFIG+=qml_debug'
+ export MER_SSH_SDK_TOOLS=/home/tone/.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default
+ exec /home/tone/dev/SailfishOS/libexec/qtcreator/merssh qmake '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++' 'CONFIG+=debug' 'CONFIG+=qml_debug'
+ /home/tone/dev/SailfishOS/bin/sfdk qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug 

and we can see that qmake also is executed with the correct command line. In fact, debota-sailfishos.pro gets passed all the way down to sfdk  .

After this, things get a little weird:

sfdk: [I] Options from environment: -c target=SailfishOS-5.0.0.62-aarch64
error: No source number 0

the first line is correct (the target is the desired one), but the second one is an error - no source number 0. Seems like an off-by-one. Let's forget about it for now, should not be too serious, hopefully.

So what happens next, is that sfdk parses the spec file, makes sure the dependencies specified in it are correctly installed; at this point, the "number 0" error re-appears; and then sfdk proceeds for the building after cd'ing into the build directory (a so-called "staged" build).
The build is started by launching qmake (again), this time to generate the correct target build files (Makefiles):

qmake -qt=5 -makefile 'QMAKE_CFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' QMAKE_STRIP=: PREFIX=/usr LIBDIR=/usr/lib64

 No .pro file is here, but you would assume that's fine, as we are in the staged build directory. and qmake should handle this correctly.

Well, 20 years of experience in the  field as told me one thing (which I call the first "rule" of development):

whenever the world "should" is involved, the assumption made is instantly and irreversably proven to be wrong, and therefore irrelevant.

So something is happening here. Lets fire up the sdk command line.

ssh -o IdentitiesOnly=yes -i <sdkinstallpath>/SailfishOS/vmshare/ssh/private_keys/sdk mersdk@localhost -p 2222

this is the way I would have done it two years (or more) ago. Nowadays, the Jollyboys have streamlined this with the sfdk utility.  So

<sdk_install_path>/SailfishOS/bin/sfdk -c target=SailfishOS-5.0.0.62-aarch64 qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

will execute the same build commands, and there you have it - this command line eats the .pro file entry.

 sfdk is a compiled binary. So we have to jump over to github to take a look. But this is an exercize for another day, given it's late now!