[oe] meta-qt5: sdk, qtcreator and OE_QMAKE_ variables

[Jean-Francois Dagenais]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20160407/04e00925/attachment-0002.sig>