meta-qt5: sdk, qtcreator and OE_QMAKE_ variables

meta-qt5: sdk, qtcreator and OE_QMAKE_ variables

[Jean-Francois Dagenais]

[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]

Hi all!

We use QtCreator on the developper desktop for much of our development. The
target builds are made with a yocto sdk which we made using "populate_sdk" with
qt4 included.

Since we jump from native builds to targeted builds, I devised a way not to use
the full sourcing of environment-setup-xyz.sh when invoking qtcreator. Doing so
would mess up the native (desktop) builds and we'd have to stop and relaunch
qtcreator many times per day. Not to mention the aggravation of not being in the
right environment and not realizing it for while when switching tasks.

We create a qtcreator "kit" composed of the yocto SDK's qmake, gcc and gdb. All
that is missing then are the OE_QMAKE_xyz variables which are put into the qmake
generated Makefiles. Using toolchain_create_sdk_env_script_append as a hook, I
generate a text file with the OE_QMAKE_xyz variables pre-expanded in a format
suitable of being copy/pasted in the "Batch Edit..." button of the build
environment setup of qtcreator projects.

Works pretty well. (Our targets were both x86_64 and x86 based). This was on
fido with qt4. Now moving onto yocto's master branch and meta-qt5, I want to
take it further and skip the whole copy/pasted env stuff. Which is an annoyance
since we each need to copy/paste for each project we setup in qtcreator and are
stored in the "volatile" .pro.user files.

If it is the case that all what's missing are the pre-expansions of OE_QMAKE_
variables, it seems like a simple task. I noticed the oe-device-extra.pri (from
the "No such file or directory" error messages I get when using the SDK). So
starting from the same sdk_env_script_append strategy, I create this file at the
proper place. By inspecting the linux-oe-g++/qmake.conf and where it includes
oe-device-extra.pri, I figured what the file should contain to properly set the
QMake variables whith pre-expanded stuff (targeted items like
arm-piko-linux-gnueabi-g++ etc.) and no longer rely on OE_QMAKE_xyz to be in the
environment.

This way I do NOT have to source the environment, the builds succeed and once
deployed, they execute (still very early in testing tough).

One more thing, we systematically relocate the SDK install to a path in the
user's home. I am in the process of reviewing if there is "leakage" into either
/opt/poky/x.y.z/... or my system.

Does anyone have any insights, warning, suggestions regarding this strategy? It
seems too easy and pretty to be true, I am thus weary. Perhaps this fits only
our limited target scenarios?


Thanks in advance!  Cheers!  /JFD


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 243 bytes --]

Re: meta-qt5: sdk, qtcreator and OE_QMAKE_ variables

[Jonathan Liu]

Hi Jean-Francois,

On 8 April 2016 at 03:21, Jean-Francois Dagenais
<jeff.dagenais@gmail.com> wrote:
> Hi all!
>
> We use QtCreator on the developper desktop for much of our development. The
> target builds are made with a yocto sdk which we made using "populate_sdk" with
> qt4 included.
>
> Since we jump from native builds to targeted builds, I devised a way not to use
> the full sourcing of environment-setup-xyz.sh when invoking qtcreator. Doing so
> would mess up the native (desktop) builds and we'd have to stop and relaunch
> qtcreator many times per day. Not to mention the aggravation of not being in the
> right environment and not realizing it for while when switching tasks.
>
> We create a qtcreator "kit" composed of the yocto SDK's qmake, gcc and gdb. All
> that is missing then are the OE_QMAKE_xyz variables which are put into the qmake
> generated Makefiles. Using toolchain_create_sdk_env_script_append as a hook, I
> generate a text file with the OE_QMAKE_xyz variables pre-expanded in a format
> suitable of being copy/pasted in the "Batch Edit..." button of the build
> environment setup of qtcreator projects.
>
> Works pretty well. (Our targets were both x86_64 and x86 based). This was on
> fido with qt4. Now moving onto yocto's master branch and meta-qt5, I want to
> take it further and skip the whole copy/pasted env stuff. Which is an annoyance
> since we each need to copy/paste for each project we setup in qtcreator and are
> stored in the "volatile" .pro.user files.
>
> If it is the case that all what's missing are the pre-expansions of OE_QMAKE_
> variables, it seems like a simple task. I noticed the oe-device-extra.pri (from
> the "No such file or directory" error messages I get when using the SDK). So
> starting from the same sdk_env_script_append strategy, I create this file at the
> proper place. By inspecting the linux-oe-g++/qmake.conf and where it includes
> oe-device-extra.pri, I figured what the file should contain to properly set the
> QMake variables whith pre-expanded stuff (targeted items like
> arm-piko-linux-gnueabi-g++ etc.) and no longer rely on OE_QMAKE_xyz to be in the
> environment.
>
> This way I do NOT have to source the environment, the builds succeed and once
> deployed, they execute (still very early in testing tough).
>
> One more thing, we systematically relocate the SDK install to a path in the
> user's home. I am in the process of reviewing if there is "leakage" into either
> /opt/poky/x.y.z/... or my system.
>
> Does anyone have any insights, warning, suggestions regarding this strategy? It
> seems too easy and pretty to be true, I am thus weary. Perhaps this fits only
> our limited target scenarios?
>
>
> Thanks in advance!  Cheers!  /JFD

On recent versions of Qt Creator, you can edit the environment for a
kit rather than a project.

I have a script which sources the environment-setup script, greps the
environment-setup and environment-setup.d/qt5.sh scripts for the names
of variables that are assigned and then greps for those variables in
the output of the env command. The output is then pasted into the
environment for the kit in Qt Creator.

Regards,
Jonathan