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

Dominik Holland dominik.holland at pelagicore.com
Mon Dec 2 18:46:32 UTC 2013


Hi,

On 02.12.2013, at 16:56, Denys Dmytriyenko <denis at 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 at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel




More information about the Openembedded-devel mailing list