Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
The webengine bug has been reported, but it's still unresolved: https://bugreports.qt.io/browse/QTBUG-57705 On Thu, Jan 12, 2017 at 9:08 PM, Martin Jansa wrote: > v5 is fine, will you also include the fix for qtwebengine on qemux86? > > Thanks > > On Thu, Jan 12, 2017 at 12:20 PM, Samuli Piippo > wrote: > >> The release date for Qt 5.8.0 is fast approaching (current target 17th of >> January). >> Would you prefer a v5 patch of this one or a new patch on top of v4? >> >> -samuli >> >> -- >> ___ >> 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
v5 is fine, will you also include the fix for qtwebengine on qemux86? Thanks On Thu, Jan 12, 2017 at 12:20 PM, Samuli Piippo wrote: > The release date for Qt 5.8.0 is fast approaching (current target 17th of > January). > Would you prefer a v5 patch of this one or a new patch on top of v4? > > -samuli > > -- > ___ > 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
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
The release date for Qt 5.8.0 is fast approaching (current target 17th of January). Would you prefer a v5 patch of this one or a new patch on top of v4? -samuli -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
On Mon, Jan 2, 2017 at 8:47 PM, Martin Jansa wrote:
> On Tue, Dec 20, 2016 at 05:30:11PM +0200, Samuli Piippo wrote:
>> On 20.12.2016 17:05, Martin Jansa wrote:
>> > On Tue, Dec 20, 2016 at 04:58:49PM +0200, Samuli Piippo wrote:
>> >> On 20.12.2016 16:30, Martin Jansa wrote:
>> >>> On Thu, Dec 15, 2016 at 04:49:55PM +0200, Samuli Piippo wrote:
>> Changes from v3 patch:
>> - sha1s updated to expected RC content
>> - fixed the qt3d assimp build-deps issue
>> - the new Qt configuration system taken into use where applicable
>>
>> webengine build problem with x86_64 host and x86 target is still there.
>> >>>
>> >>> This version seems to fail in qtwayland:
>> >>>
>> >>> http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161218_140914.log//2_max/failed/qtwayland.log
>> >>>
>> >>> | ERROR: Feature 'xcomposite-glx' was enabled, but the pre-condition
>> >>> 'features.wayland-client && features.opengl && !features.opengles2 &&
>> >>> libs.xcomposite && libs.glx' failed.
>> >>
>> >> What kind of configuration is used for qtbase?
>> >> To me it seems that one of these checks fail: features.opengl &&
>> >> !features.opengles2
>> >
>> > The same as when building previous version of this patch.
>> >
>> > on top of meta-qt5 default there is:
>> >
>> > PACKAGECONFIG_GL = "gles2 eglfs"
>>
>> The gles2 here causes the failure, since xcomposite-glx checks for
>> "!features.opengles2"
>> This makes sense since you want to have desktop opengl enabled together
>> with wayland GLX.
>
> Then is it correct to enable both xcomposite-egl and xcomposite-glx for
> x11 in DISTRO_FEATUREs?
>
> Without this change in qtwayland_git.bb:
>
> -${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xcompositor xkb glx',
> '', d)} \
> +${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xcomposite-egl
> xcomposite-glx', '', d)} \
>
> I can build again with that configuration.
It kind of depends what we expect the default to be.
If you have x11+opengl in DISTRO_FEATURES, then I think expectation is
to build xcb-glx plugin in qtbase and xcomposite-glx plugin in
qtwayland, which work together.
If you configure qtbase with gles2, xcb-glx won't be built and
qtwayland cannot be configured with xcomposite-glx.
Just noticed that we are missing PACKAGECONFIG[egl] in qtbase.
If that's added and if that's not used in the default PACKAGECONFIG_GL
list, we then have to remove xcomposite-egl and wayland-egl from
qtwayland defaults.
so it's also question how far we want to go with the PACKAGECONFIGs.
>
>> > PACKAGECONFIG_DISTRO = "sql-sqlite icu glib accessibility mtdev examples
>> > fontconfig"
>> >
>> > QT_CONFIG_FLAGS += "-qpa wayland-egl"
>> >
>> > from meta-luneui/recipes-qt/qt5/qtbase_git.bbappend
>> >
>> > and
>> > PACKAGECONFIG_append_pn-qtbase = " freetype fontconfig"
>> > from world_fixes.inc
>> > http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemuarm.20161217_135213.log/world_fixes.inc
>> >>
>> >>>
>> >>> Is the configure more strict in new version or do we need to change the
>> >>> default config for qtwayland builds?
>> >>>
>>
>> -samuli
>>
>> On 15.12.2016 15:48, Samuli Piippo wrote:
>> > The linux-oe-g++ mkspec is changed to use $$(...) operator to obtain
>> > the contents of an environment value when qmake is run instead of when
>> > Makefile is processed. All OE_QMAKE_xxx variables need to be exported
>> > for qmake to find them. configure's setBootstrapVariable function needs
>> > to change $$(..) to normal $(...) operator to work with qmake's
>> > Makefile.
>> >
>> > qt.conf generation for qtbase recipes is not needed, as configure will
>> > generate its own version based on configure arguments. Skip running
>> > qmake, since configure is now automatically invoked when it's run in
>> > qtbase's root folder.
>> >
>> > Update PACKAGECONFIGs for qtbase to match current configure options.
>> >
>> > The new Qt configuration system [1] can be used with a new variable
>> > EXTRA_QMAKEVARS_CONFIGURE, which takes both command line and feature
>> > arguments.
>> >
>> > Merge the two qtwayland recipes to one that supports all three targets
>> > (target, native, nativesdk) without need for additional patch.
>> >
>> > [1]
>> > https://www.mail-archive.com/development@qt-project.org/msg25257.html
>> >
>> --
>> ___
>> 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
>> >
>> >
>> >
>> --
>> ___
>> Openembedded-devel mailin
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
On Tue, Dec 20, 2016 at 05:30:11PM +0200, Samuli Piippo wrote:
> On 20.12.2016 17:05, Martin Jansa wrote:
> > On Tue, Dec 20, 2016 at 04:58:49PM +0200, Samuli Piippo wrote:
> >> On 20.12.2016 16:30, Martin Jansa wrote:
> >>> On Thu, Dec 15, 2016 at 04:49:55PM +0200, Samuli Piippo wrote:
> Changes from v3 patch:
> - sha1s updated to expected RC content
> - fixed the qt3d assimp build-deps issue
> - the new Qt configuration system taken into use where applicable
>
> webengine build problem with x86_64 host and x86 target is still there.
> >>>
> >>> This version seems to fail in qtwayland:
> >>>
> >>> http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161218_140914.log//2_max/failed/qtwayland.log
> >>>
> >>> | ERROR: Feature 'xcomposite-glx' was enabled, but the pre-condition
> >>> 'features.wayland-client && features.opengl && !features.opengles2 &&
> >>> libs.xcomposite && libs.glx' failed.
> >>
> >> What kind of configuration is used for qtbase?
> >> To me it seems that one of these checks fail: features.opengl &&
> >> !features.opengles2
> >
> > The same as when building previous version of this patch.
> >
> > on top of meta-qt5 default there is:
> >
> > PACKAGECONFIG_GL = "gles2 eglfs"
>
> The gles2 here causes the failure, since xcomposite-glx checks for
> "!features.opengles2"
> This makes sense since you want to have desktop opengl enabled together
> with wayland GLX.
Then is it correct to enable both xcomposite-egl and xcomposite-glx for
x11 in DISTRO_FEATUREs?
Without this change in qtwayland_git.bb:
-${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xcompositor xkb glx', '',
d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xcomposite-egl
xcomposite-glx', '', d)} \
I can build again with that configuration.
> > PACKAGECONFIG_DISTRO = "sql-sqlite icu glib accessibility mtdev examples
> > fontconfig"
> >
> > QT_CONFIG_FLAGS += "-qpa wayland-egl"
> >
> > from meta-luneui/recipes-qt/qt5/qtbase_git.bbappend
> >
> > and
> > PACKAGECONFIG_append_pn-qtbase = " freetype fontconfig"
> > from world_fixes.inc
> > http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemuarm.20161217_135213.log/world_fixes.inc
> >>
> >>>
> >>> Is the configure more strict in new version or do we need to change the
> >>> default config for qtwayland builds?
> >>>
>
> -samuli
>
> On 15.12.2016 15:48, Samuli Piippo wrote:
> > The linux-oe-g++ mkspec is changed to use $$(...) operator to obtain
> > the contents of an environment value when qmake is run instead of when
> > Makefile is processed. All OE_QMAKE_xxx variables need to be exported
> > for qmake to find them. configure's setBootstrapVariable function needs
> > to change $$(..) to normal $(...) operator to work with qmake's
> > Makefile.
> >
> > qt.conf generation for qtbase recipes is not needed, as configure will
> > generate its own version based on configure arguments. Skip running
> > qmake, since configure is now automatically invoked when it's run in
> > qtbase's root folder.
> >
> > Update PACKAGECONFIGs for qtbase to match current configure options.
> >
> > The new Qt configuration system [1] can be used with a new variable
> > EXTRA_QMAKEVARS_CONFIGURE, which takes both command line and feature
> > arguments.
> >
> > Merge the two qtwayland recipes to one that supports all three targets
> > (target, native, nativesdk) without need for additional patch.
> >
> > [1]
> > https://www.mail-archive.com/development@qt-project.org/msg25257.html
> >
> --
> ___
> 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
> >
> >
> >
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
On 20.12.2016 17:05, Martin Jansa wrote: On Tue, Dec 20, 2016 at 04:58:49PM +0200, Samuli Piippo wrote: On 20.12.2016 16:30, Martin Jansa wrote: On Thu, Dec 15, 2016 at 04:49:55PM +0200, Samuli Piippo wrote: Changes from v3 patch: - sha1s updated to expected RC content - fixed the qt3d assimp build-deps issue - the new Qt configuration system taken into use where applicable webengine build problem with x86_64 host and x86 target is still there. This version seems to fail in qtwayland: http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161218_140914.log//2_max/failed/qtwayland.log | ERROR: Feature 'xcomposite-glx' was enabled, but the pre-condition 'features.wayland-client && features.opengl && !features.opengles2 && libs.xcomposite && libs.glx' failed. What kind of configuration is used for qtbase? To me it seems that one of these checks fail: features.opengl && !features.opengles2 The same as when building previous version of this patch. on top of meta-qt5 default there is: PACKAGECONFIG_GL = "gles2 eglfs" The gles2 here causes the failure, since xcomposite-glx checks for "!features.opengles2" This makes sense since you want to have desktop opengl enabled together with wayland GLX. PACKAGECONFIG_DISTRO = "sql-sqlite icu glib accessibility mtdev examples fontconfig" QT_CONFIG_FLAGS += "-qpa wayland-egl" from meta-luneui/recipes-qt/qt5/qtbase_git.bbappend and PACKAGECONFIG_append_pn-qtbase = " freetype fontconfig" from world_fixes.inc http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemuarm.20161217_135213.log/world_fixes.inc Is the configure more strict in new version or do we need to change the default config for qtwayland builds? -samuli On 15.12.2016 15:48, Samuli Piippo wrote: The linux-oe-g++ mkspec is changed to use $$(...) operator to obtain the contents of an environment value when qmake is run instead of when Makefile is processed. All OE_QMAKE_xxx variables need to be exported for qmake to find them. configure's setBootstrapVariable function needs to change $$(..) to normal $(...) operator to work with qmake's Makefile. qt.conf generation for qtbase recipes is not needed, as configure will generate its own version based on configure arguments. Skip running qmake, since configure is now automatically invoked when it's run in qtbase's root folder. Update PACKAGECONFIGs for qtbase to match current configure options. The new Qt configuration system [1] can be used with a new variable EXTRA_QMAKEVARS_CONFIGURE, which takes both command line and feature arguments. Merge the two qtwayland recipes to one that supports all three targets (target, native, nativesdk) without need for additional patch. [1] https://www.mail-archive.com/development@qt-project.org/msg25257.html -- ___ 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
On 20.12.2016 16:30, Martin Jansa wrote: On Thu, Dec 15, 2016 at 04:49:55PM +0200, Samuli Piippo wrote: Changes from v3 patch: - sha1s updated to expected RC content - fixed the qt3d assimp build-deps issue - the new Qt configuration system taken into use where applicable webengine build problem with x86_64 host and x86 target is still there. This version seems to fail in qtwayland: http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161218_140914.log//2_max/failed/qtwayland.log | ERROR: Feature 'xcomposite-glx' was enabled, but the pre-condition 'features.wayland-client && features.opengl && !features.opengles2 && libs.xcomposite && libs.glx' failed. What kind of configuration is used for qtbase? To me it seems that one of these checks fail: features.opengl && !features.opengles2 Is the configure more strict in new version or do we need to change the default config for qtwayland builds? -samuli On 15.12.2016 15:48, Samuli Piippo wrote: The linux-oe-g++ mkspec is changed to use $$(...) operator to obtain the contents of an environment value when qmake is run instead of when Makefile is processed. All OE_QMAKE_xxx variables need to be exported for qmake to find them. configure's setBootstrapVariable function needs to change $$(..) to normal $(...) operator to work with qmake's Makefile. qt.conf generation for qtbase recipes is not needed, as configure will generate its own version based on configure arguments. Skip running qmake, since configure is now automatically invoked when it's run in qtbase's root folder. Update PACKAGECONFIGs for qtbase to match current configure options. The new Qt configuration system [1] can be used with a new variable EXTRA_QMAKEVARS_CONFIGURE, which takes both command line and feature arguments. Merge the two qtwayland recipes to one that supports all three targets (target, native, nativesdk) without need for additional patch. [1] https://www.mail-archive.com/development@qt-project.org/msg25257.html -- ___ 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
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
On Tue, Dec 20, 2016 at 04:58:49PM +0200, Samuli Piippo wrote: > On 20.12.2016 16:30, Martin Jansa wrote: > > On Thu, Dec 15, 2016 at 04:49:55PM +0200, Samuli Piippo wrote: > >> Changes from v3 patch: > >> - sha1s updated to expected RC content > >> - fixed the qt3d assimp build-deps issue > >> - the new Qt configuration system taken into use where applicable > >> > >> webengine build problem with x86_64 host and x86 target is still there. > > > > This version seems to fail in qtwayland: > > > > http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161218_140914.log//2_max/failed/qtwayland.log > > > > | ERROR: Feature 'xcomposite-glx' was enabled, but the pre-condition > > 'features.wayland-client && features.opengl && !features.opengles2 && > > libs.xcomposite && libs.glx' failed. > > What kind of configuration is used for qtbase? > To me it seems that one of these checks fail: features.opengl && > !features.opengles2 The same as when building previous version of this patch. on top of meta-qt5 default there is: PACKAGECONFIG_GL = "gles2 eglfs" PACKAGECONFIG_DISTRO = "sql-sqlite icu glib accessibility mtdev examples fontconfig" QT_CONFIG_FLAGS += "-qpa wayland-egl" from meta-luneui/recipes-qt/qt5/qtbase_git.bbappend and PACKAGECONFIG_append_pn-qtbase = " freetype fontconfig" from world_fixes.inc http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemuarm.20161217_135213.log/world_fixes.inc > > > > > Is the configure more strict in new version or do we need to change the > > default config for qtwayland builds? > > > >> > >> -samuli > >> > >> On 15.12.2016 15:48, Samuli Piippo wrote: > >>> The linux-oe-g++ mkspec is changed to use $$(...) operator to obtain > >>> the contents of an environment value when qmake is run instead of when > >>> Makefile is processed. All OE_QMAKE_xxx variables need to be exported > >>> for qmake to find them. configure's setBootstrapVariable function needs > >>> to change $$(..) to normal $(...) operator to work with qmake's Makefile. > >>> > >>> qt.conf generation for qtbase recipes is not needed, as configure will > >>> generate its own version based on configure arguments. Skip running > >>> qmake, since configure is now automatically invoked when it's run in > >>> qtbase's root folder. > >>> > >>> Update PACKAGECONFIGs for qtbase to match current configure options. > >>> > >>> The new Qt configuration system [1] can be used with a new variable > >>> EXTRA_QMAKEVARS_CONFIGURE, which takes both command line and feature > >>> arguments. > >>> > >>> Merge the two qtwayland recipes to one that supports all three targets > >>> (target, native, nativesdk) without need for additional patch. > >>> > >>> [1] https://www.mail-archive.com/development@qt-project.org/msg25257.html > >>> > >> -- > >> ___ > >> 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 -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
On Thu, Dec 15, 2016 at 04:49:55PM +0200, Samuli Piippo wrote: > Changes from v3 patch: > - sha1s updated to expected RC content > - fixed the qt3d assimp build-deps issue > - the new Qt configuration system taken into use where applicable > > webengine build problem with x86_64 host and x86 target is still there. This version seems to fail in qtwayland: http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161218_140914.log//2_max/failed/qtwayland.log | ERROR: Feature 'xcomposite-glx' was enabled, but the pre-condition 'features.wayland-client && features.opengl && !features.opengles2 && libs.xcomposite && libs.glx' failed. Is the configure more strict in new version or do we need to change the default config for qtwayland builds? > > -samuli > > On 15.12.2016 15:48, Samuli Piippo wrote: > > The linux-oe-g++ mkspec is changed to use $$(...) operator to obtain > > the contents of an environment value when qmake is run instead of when > > Makefile is processed. All OE_QMAKE_xxx variables need to be exported > > for qmake to find them. configure's setBootstrapVariable function needs > > to change $$(..) to normal $(...) operator to work with qmake's Makefile. > > > > qt.conf generation for qtbase recipes is not needed, as configure will > > generate its own version based on configure arguments. Skip running > > qmake, since configure is now automatically invoked when it's run in > > qtbase's root folder. > > > > Update PACKAGECONFIGs for qtbase to match current configure options. > > > > The new Qt configuration system [1] can be used with a new variable > > EXTRA_QMAKEVARS_CONFIGURE, which takes both command line and feature > > arguments. > > > > Merge the two qtwayland recipes to one that supports all three targets > > (target, native, nativesdk) without need for additional patch. > > > > [1] https://www.mail-archive.com/development@qt-project.org/msg25257.html > > > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
Hi, thanks for the job! Is this on the master of meta-qt5? If so I will be able to check if this patch 0009-Reorder-EGL-libraries-from-pkgconfig-and-defaults.patch is still needed or not. I hope not. Regards, On 2016-12-15 15:49, Samuli Piippo wrote: Changes from v3 patch: - sha1s updated to expected RC content - fixed the qt3d assimp build-deps issue - the new Qt configuration system taken into use where applicable webengine build problem with x86_64 host and x86 target is still there. -samuli On 15.12.2016 15:48, Samuli Piippo wrote: The linux-oe-g++ mkspec is changed to use $$(...) operator to obtain the contents of an environment value when qmake is run instead of when Makefile is processed. All OE_QMAKE_xxx variables need to be exported for qmake to find them. configure's setBootstrapVariable function needs to change $$(..) to normal $(...) operator to work with qmake's Makefile. qt.conf generation for qtbase recipes is not needed, as configure will generate its own version based on configure arguments. Skip running qmake, since configure is now automatically invoked when it's run in qtbase's root folder. Update PACKAGECONFIGs for qtbase to match current configure options. The new Qt configuration system [1] can be used with a new variable EXTRA_QMAKEVARS_CONFIGURE, which takes both command line and feature arguments. Merge the two qtwayland recipes to one that supports all three targets (target, native, nativesdk) without need for additional patch. [1] https://www.mail-archive.com/development@qt-project.org/msg25257.html -- "Yesterday is history, Tomorrow is a mystery, But today is a gift. That is why it is called the "present"." Adress: 29 Boulevard Joseph Garnier 06100 Nice FRANCE Mobile: +33 6 17 98 03 83 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.8
Changes from v3 patch: - sha1s updated to expected RC content - fixed the qt3d assimp build-deps issue - the new Qt configuration system taken into use where applicable webengine build problem with x86_64 host and x86 target is still there. -samuli On 15.12.2016 15:48, Samuli Piippo wrote: The linux-oe-g++ mkspec is changed to use $$(...) operator to obtain the contents of an environment value when qmake is run instead of when Makefile is processed. All OE_QMAKE_xxx variables need to be exported for qmake to find them. configure's setBootstrapVariable function needs to change $$(..) to normal $(...) operator to work with qmake's Makefile. qt.conf generation for qtbase recipes is not needed, as configure will generate its own version based on configure arguments. Skip running qmake, since configure is now automatically invoked when it's run in qtbase's root folder. Update PACKAGECONFIGs for qtbase to match current configure options. The new Qt configuration system [1] can be used with a new variable EXTRA_QMAKEVARS_CONFIGURE, which takes both command line and feature arguments. Merge the two qtwayland recipes to one that supports all three targets (target, native, nativesdk) without need for additional patch. [1] https://www.mail-archive.com/development@qt-project.org/msg25257.html -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
