[meta-qt5][PATCH 0/2] Add nativesdk tools for Qt5 SDK

[meta-qt5][PATCH 0/2] Add nativesdk tools for Qt5 SDK

[Denys Dmytriyenko]

From: Denys Dmytriyenko <denys@ti.com>

This patchset adds nativesdk versions of qtbase(-tools) and qttools to be
used by Qt5 SDK.

I also have corresponding packagegroup and meta-toolchain recipes for packaging
up the Qt5 SDK, which I can submit later, once I have them cleaned up.

This has been validated and tested inside the Arago Project distro for a few
weeks using generated Qt5 SDK to cross-compile example applications either on
the command line or in QtCreator.

Denys Dmytriyenko (2):
  nativesdk-qtbase: add nativesdk version of qtbase necessary for SDK
    tools
  nativesdk-qttools: add nativesdk version of qttools necessary for SDK
    tools

 recipes-qt/qt5/nativesdk-qt5.inc                   |  12 ++
 recipes-qt/qt5/nativesdk-qtbase.inc                | 193 +++++++++++++++++++++
 ...ump-path-length-from-256-to-512-character.patch |  29 ++++
 ...reserve-built-qmake-and-swap-with-native-.patch |  29 ++++
 recipes-qt/qt5/nativesdk-qtbase_5.1.1.bb           |   7 +
 recipes-qt/qt5/nativesdk-qttools.inc               |  32 ++++
 recipes-qt/qt5/nativesdk-qttools_5.1.1.bb          |  12 ++
 7 files changed, 314 insertions(+)
 create mode 100644 recipes-qt/qt5/nativesdk-qt5.inc
 create mode 100644 recipes-qt/qt5/nativesdk-qtbase.inc
 create mode 100644 recipes-qt/qt5/nativesdk-qtbase/0001-configure-bump-path-length-from-256-to-512-character.patch
 create mode 100644 recipes-qt/qt5/nativesdk-qtbase/0001-configure-preserve-built-qmake-and-swap-with-native-.patch
 create mode 100644 recipes-qt/qt5/nativesdk-qtbase_5.1.1.bb
 create mode 100644 recipes-qt/qt5/nativesdk-qttools.inc
 create mode 100644 recipes-qt/qt5/nativesdk-qttools_5.1.1.bb

-- 
1.8.3.2

[meta-qt5][PATCH 0/2] Add nativesdk tools for Qt5 SDK

[Dominik Holland]

Hi all,

i'm the author of the merge-request on github.

The patchset from Denys looks nice. Especially because it cross compiles 
the host tools for the SDK_MACHINE which i forgot todo in my patchset.

I think the best way would be a combined version of both patchsets.

Because some of you think my patchset is too complicated i want to 
highlight why i added the complicated creation of the qt.conf and the 
additional patching of the mkspec files etc.

I didn't tested Denys version but i think it only works if you source 
the environment scripts of the SDK before.

As a Qt developer it's the defacto standard to get a SDK which works out 
of the box for your projects by just invoking qmake and no need to 
source a script before which changes your environment.

To get this done you need to patch the mkspec folder and the qt.conf to 
use relative paths instead the hardcoded paths which where created 
during the yocto build.

In addition i created a linux-oe-sdk-g++ which contains the real values 
of the environment variables but without --sysroot. This will be set by 
qt itself by using the CROSS_COMPILE prefix.


I hope you understand that this is really needed if you want to get a 
good qt5 integration into a OE SDK.

Best Reagrds

  Dominik

P.S. If you want to use the qmake inside qtcreator you would need to set 
all the env variable of the environment script inside qtcreator which is 
really inconvenient

Re: [meta-qt5][PATCH 0/2] Add nativesdk tools for Qt5 SDK

[Denys Dmytriyenko]

Sorry for top-posting, but I wanted to reply in general and couldn't find the 
right place for inlining...

Anyway, the below assumptions aren't exactly correct. And the main one being - 
you don't really need to source the environment-setup script. But you'd need a 
different and much simpler qt.conf, which I populate as part of the 
meta-toolchain recipe (still pending submission though). And you can use 
relative paths in that generated qt.conf so qmake can be used w/o sourcing the 
environment-setup script. But even with absolute paths those will be fixed 
automatically by the SDK setup script at the install time...

The thing is, you cannot re-use the same qt.conf that you generate for the 
nativesdk tools, because that one is for cross-compiling for SDK. Like you 
mentioned, it cross-compiles the tools for SDK_MACHINE, which is different 
from target MACHINE as well as the build host. When the tools are used, you 
need a different qt.conf with a makespec to run on SDK_MACHINE and build for 
target MACHINE.

Also, I wanted the things to be as simple as possible, so I decided to re-use 
linux-oe-g++ makespec, as it is already there and we've been using it 
successfully for a long time with Qt4. The only thing is, existing 
linux-oe-g++ relies on the OE-specific variables, because that was the way OE 
SDK always worked.

-- 
Denys


On Mon, Dec 02, 2013 at 01:10:56PM +0100, Dominik Holland wrote:
> Hi all,
> 
> i'm the author of the merge-request on github.
> 
> The patchset from Denys looks nice. Especially because it cross
> compiles the host tools for the SDK_MACHINE which i forgot todo in
> my patchset.
> 
> I think the best way would be a combined version of both patchsets.
> 
> Because some of you think my patchset is too complicated i want to
> highlight why i added the complicated creation of the qt.conf and
> the additional patching of the mkspec files etc.
> 
> I didn't tested Denys version but i think it only works if you
> source the environment scripts of the SDK before.
> 
> As a Qt developer it's the defacto standard to get a SDK which works
> out of the box for your projects by just invoking qmake and no need
> to source a script before which changes your environment.
> 
> To get this done you need to patch the mkspec folder and the qt.conf
> to use relative paths instead the hardcoded paths which where
> created during the yocto build.
> 
> In addition i created a linux-oe-sdk-g++ which contains the real
> values of the environment variables but without --sysroot. This will
> be set by qt itself by using the CROSS_COMPILE prefix.
> 
> 
> I hope you understand that this is really needed if you want to get
> a good qt5 integration into a OE SDK.
> 
> Best Reagrds
> 
>  Dominik
> 
> P.S. If you want to use the qmake inside qtcreator you would need to
> set all the env variable of the environment script inside qtcreator
> which is really inconvenient
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [meta-qt5][PATCH 0/2] Add nativesdk tools for Qt5 SDK

[Dominik Holland]

Hi,

On 02.12.2013, at 16:56, Denys Dmytriyenko <denis@denix.org> wrote:

> Sorry for top-posting, but I wanted to reply in general and couldn't find the 
> right place for inlining...
> 
> Anyway, the below assumptions aren't exactly correct. And the main one being - 
> you don't really need to source the environment-setup script. But you'd need a 
> different and much simpler qt.conf, which I populate as part of the 
> meta-toolchain recipe (still pending submission though). And you can use 
> relative paths in that generated qt.conf so qmake can be used w/o sourcing the 
> environment-setup script. But even with absolute paths those will be fixed 
> automatically by the SDK setup script at the install time…

ok great, if you have a much simpler qt.conf which is populated and works. I'm find with that ;-)

> 
> The thing is, you cannot re-use the same qt.conf that you generate for the 
> nativesdk tools, because that one is for cross-compiling for SDK. Like you 
> mentioned, it cross-compiles the tools for SDK_MACHINE, which is different 
> from target MACHINE as well as the build host. When the tools are used, you 
> need a different qt.conf with a makespec to run on SDK_MACHINE and build for 
> target MACHINE.

I know, and i didn't said anything that i wanted to do that.

> 
> Also, I wanted the things to be as simple as possible, so I decided to re-use 
> linux-oe-g++ makespec, as it is already there and we've been using it 
> successfully for a long time with Qt4. The only thing is, existing 
> linux-oe-g++ relies on the OE-specific variables, because that was the way OE 
> SDK always worked.

I'm also fine with that.

What i'm really up to is to fix the hardcoded paths in mkspecs/qdevice.pri and mkspecs/qconfig.pri

Don't get me wrong i really appreciate your work, i only want to make sure that the result works in every way and a qt-developer doesn't have to do any additional setup before he can use the SDK.

Have fun!
 Dominik

> 
> -- 
> Denys
> 
> 
> On Mon, Dec 02, 2013 at 01:10:56PM +0100, Dominik Holland wrote:
>> Hi all,
>> 
>> i'm the author of the merge-request on github.
>> 
>> The patchset from Denys looks nice. Especially because it cross
>> compiles the host tools for the SDK_MACHINE which i forgot todo in
>> my patchset.
>> 
>> I think the best way would be a combined version of both patchsets.
>> 
>> Because some of you think my patchset is too complicated i want to
>> highlight why i added the complicated creation of the qt.conf and
>> the additional patching of the mkspec files etc.
>> 
>> I didn't tested Denys version but i think it only works if you
>> source the environment scripts of the SDK before.
>> 
>> As a Qt developer it's the defacto standard to get a SDK which works
>> out of the box for your projects by just invoking qmake and no need
>> to source a script before which changes your environment.
>> 
>> To get this done you need to patch the mkspec folder and the qt.conf
>> to use relative paths instead the hardcoded paths which where
>> created during the yocto build.
>> 
>> In addition i created a linux-oe-sdk-g++ which contains the real
>> values of the environment variables but without --sysroot. This will
>> be set by qt itself by using the CROSS_COMPILE prefix.
>> 
>> 
>> I hope you understand that this is really needed if you want to get
>> a good qt5 integration into a OE SDK.
>> 
>> Best Reagrds
>> 
>> Dominik
>> 
>> P.S. If you want to use the qmake inside qtcreator you would need to
>> set all the env variable of the environment script inside qtcreator
>> which is really inconvenient
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel