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