Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries
On 9/11/2015 9:19 AM, René J.V. Bertin wrote: > On Friday September 11 2015 14:17:23 René J.V. Bertin wrote: > >> How can I find out why QMAKE_LIBS_OPENGL gets set to -lGL in qmodule.pri, or >> why the library is tested in opengldesktop.pro? > > Answer 1: by sinking teeth where I'd rather not sink them > Answer 2: configure shouldn't use pkg-config when building for the Cocoa QPA, > i.o.w, > > if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" = > "" -a "$XPLATFORM_MAC" = "yes" ] then compileTest should be used. I cannot > see any reason to justify using pkg-config to find the OpenGL frameworks, > just as it's obvious that it should be used to find the GLX library when > building the XCB plugin. > > Should I file a bug report or is this enough? This is the bug report I previously filed on this: https://bugreports.qt.io/browse/QTBUG-47146 It's definitely a problem caused by pkg-config if your pkg-config is set to search your X11 installation by default (using PKG_CONFIG_LIBDIR at least can override the default). A conditional that *doesn't* use pkg-config to find OpenGL on Cocoa would be very nice. Hanspeter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Qt 5.5.1 branching ongoing
On Fri, Sep 04, 2015 at 07:50:39AM +, Heikkinen Jani wrote: > '5.5.1' branch is now available, please start using it for the changes > targeted to Qt5.5.1 release. We will merge '5.5' branch to '5.5.1' Friday > 11th September so there should be enough time to finalize ongoing changes in > '5.5'. All new changes for Qt5.5.1 should be done in '5.5.1' branch from now > on. > the branching of 5.5.1 is now complete. changes integrated into 5.5 are now 5.5.2 (or more probably 5.6) material. > Target is to release Qt5.5.1 during September so please make sure all > blockers will be fixed as soon as possible. And please remember: Do not add > any nice to have -changes in anymore. > > Best regards, > Jani Heikkinen > Release Manager | The Qt Company > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland > Email: jani.heikki...@theqtcompany.com | Mobile: + 358 50 48 73 735 > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, > @Qtproject Facebook: www.facebook.com/qt > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries
On Friday September 11 2015 20:18:20 Oswald Buddenhagen wrote: > > if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" > > = "" -a "$XPLATFORM_MAC" = "yes" ] then compileTest should be used. I > > cannot see any reason to justify using pkg-config to find the OpenGL > > frameworks, just as it's obvious that it should be used to find the GLX > > library when building the XCB plugin. > > > > Should I file a bug report or is this enough? > > > there are some related reports already. > > but what you really should do, is contribute a patch. ;) I actually already provided the patch ;) (but I guess I won't get out from doing a full-blown gerrit even for this...) R ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries
On Fri, Sep 11, 2015 at 04:19:52PM +0200, René J.V. Bertin wrote: > On Friday September 11 2015 14:17:23 René J.V. Bertin wrote: > > > How can I find out why QMAKE_LIBS_OPENGL gets set to -lGL in qmodule.pri, > > or why the library is tested in opengldesktop.pro? > > Answer 1: by sinking teeth where I'd rather not sink them > Answer 2: configure shouldn't use pkg-config when building for the Cocoa QPA, > i.o.w, > > if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" = > "" -a "$XPLATFORM_MAC" = "yes" ] then compileTest should be used. I cannot > see any reason to justify using pkg-config to find the OpenGL frameworks, > just as it's obvious that it should be used to find the GLX library when > building the XCB plugin. > > Should I file a bug report or is this enough? > there are some related reports already. but what you really should do, is contribute a patch. ;) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWebEngine unbundled of third-party libraries on Linux
On Friday 11 September 2015, Lisandro Damián Nicanor Pérez Meyer wrote: > On Tuesday 11 August 2015 23:17:31 Allan Sandfeld Jensen wrote: > > Hello Qt > > > > QtWebEngine and Chromium in the Qt 5.6 branch have been patched to allow > > linking with system libraries on Linux instead of bundled libraries. For > > most libraries the system library will be used if development files are > > detected on the system. ICU and FFMPEG however defaults to using the > > bundled copies and requires using qmake arguments to configure to use > > system versions. The required arguments are listed in qmake configure > > status (just delete .qmake.cache and run qmake to run the configure step > > again). Note that for FFMPEG, the libav libraries from the FFMPEG project > > are required, the libraries from the libav project does not work. > > > > I have so far only tested on Debian. If more people could test it we > > could also get better detection and set proper minimal versions. > > > > If you are a packager and more is required before QtWebEngine can be > > packaged on your distribution, please let me know. > > [Exactly one month later...] > > I'll try to check this during the weekend. I'm terribly sorry for not doing > it sooner, but life gets in the middle too much lately :-/ > > Do you think it would be possible to build it against Qt 5.5? Just for > testing purposes, of course. Yes it does, and I intend to to keep it that way :D It is not a supported configuration, but to the extend it is possible, I will try to make Qt WebEngine build with one version older Qt. With QtWebKit I kept it working with two version older, but WebEngine moves much faster and has a tight integration with the scene graph, so let's see. Btw. If you know the people packaging Chromium, you could point them my way, we could probably share patches. Best regards `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWebEngine unbundled of third-party libraries on Linux
On Tuesday 11 August 2015 23:17:31 Allan Sandfeld Jensen wrote: > Hello Qt > > QtWebEngine and Chromium in the Qt 5.6 branch have been patched to allow > linking with system libraries on Linux instead of bundled libraries. For > most libraries the system library will be used if development files are > detected on the system. ICU and FFMPEG however defaults to using the > bundled copies and requires using qmake arguments to configure to use > system versions. The required arguments are listed in qmake configure > status (just delete .qmake.cache and run qmake to run the configure step > again). Note that for FFMPEG, the libav libraries from the FFMPEG project > are required, the libraries from the libav project does not work. > > I have so far only tested on Debian. If more people could test it we could > also get better detection and set proper minimal versions. > > If you are a packager and more is required before QtWebEngine can be > packaged on your distribution, please let me know. [Exactly one month later...] I'll try to check this during the weekend. I'm terribly sorry for not doing it sooner, but life gets in the middle too much lately :-/ Do you think it would be possible to build it against Qt 5.5? Just for testing purposes, of course. -- Hacer algo siempre te llevará más tiempo del que esperabas, incluso si tienes en cuenta la ley de Hofstadter. Douglas Hofstadter http://mundogeek.net/archivos/2009/09/05/la-ley-de-hofstadter/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries
On Friday September 11 2015 14:17:23 René J.V. Bertin wrote: > How can I find out why QMAKE_LIBS_OPENGL gets set to -lGL in qmodule.pri, or > why the library is tested in opengldesktop.pro? Answer 1: by sinking teeth where I'd rather not sink them Answer 2: configure shouldn't use pkg-config when building for the Cocoa QPA, i.o.w, if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" = "" -a "$XPLATFORM_MAC" = "yes" ] then compileTest should be used. I cannot see any reason to justify using pkg-config to find the OpenGL frameworks, just as it's obvious that it should be used to find the GLX library when building the XCB plugin. Should I file a bug report or is this enough? R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries
Hi, Another build issue on OS X: the build system picks up the wrong OpenGL library. This happens when the GLX libGL.dylib is present in the library path (e.g. when building under MacPorts), probably because QMAKE_LIBS_OPENGL contains -lGL . With Qt 5.4 the GLX library wasn't found when building for XCB, but obviously it should be ignored when building the native, cocoa variant. How can I find out why QMAKE_LIBS_OPENGL gets set to -lGL in qmodule.pri, or why the library is tested in opengldesktop.pro? For reference, this is my current configure command: %> configure -platform macx-clang -sdk macosx10.9 -prefix /opt/local -archdatadir /opt/local/libexec/qt5 -docdir /opt/local/share/doc/qt5 -headerdir /opt/local/include/qt5 -plugindir /opt/local/share/qt5/plugins -importdir /opt/local/share/qt5/imports -qmldir /opt/local/share/qt5/qml -datadir /opt/local/share/qt5 -libdir /opt/local/libexec/qt5/Library/Frameworks -bindir /opt/local/libexec/qt5/bin -libexecdir /opt/local/libexec/qt5/libexec -translationdir /opt/local/share/qt5/translations -sysconfdir /opt/local/etc/qt5 -examplesdir /Applications/MacPorts/Qt5/examples -testsdir /opt/local/share/qt5/tests -hostbindir /opt/local/libexec/qt5/bin -hostlibdir /opt/local/libexec/qt5/Library/Frameworks -hostdatadir /opt/local/share/qt5 -v -release -opensource -confirm-license -shared -force-pkg-config -no-pulseaudio -no-mtdev -system-harfbuzz -openssl-linked -no-xinput2 -no-xcb -no-xcb-xlib -no-libudev -no-egl -make libs -make tools -nomake examples -nomake tests -verbose -nis -cups - iconv -no-evdev -icu -fontconfig -no-pch -dbus-linked -glib -directfb -no-linuxfb -no-kms -no-use-gold-linker -framework -optimized-qmake -system-sqlite -no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc -no-sql-psql -no-sql-sqlite2 -no-sql-tds -no-openvg -force-debug-info -no-strip -no-separate-debug-info R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWaylandCompositor public api
On Wednesday 9. September 2015 18.13.55 Thomas Senyk wrote: > How stable/done is this? Is it worth while trying to port an existing > compositor to the new API? It's in active API review, and we're still tearing down some of the classes. Right now, we are removing absolute positions from the API, since that concept does not really exist in Wayland. We also know that we have to change the input classes. > If it's stable enough to count an effort like that between "API > review" and "actual forward port" then I'd give it a try in 2-3 weeks > (unless something comes up -- as always). In 2-3 weeks, the API should be a lot more stable. That would be the ideal time to give feedback. > What's assumed ETA for moving wip-compositor-api to default API? 5.6? 5.7? We will have a tech preview in the 5.6 timeframe, but we will integrate the changes to the dev branch, and not to the 5.6 branch. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development