Re: [kde-freebsd] Qt 5 and GCC4.9.3
On Wed, 20 May 2015 08:03:40 + (UTC) Dirk Niebelus dirkniebe...@yahoo.de wrote: Hello, I'm using Freebsd 9 (current FreeNAS) and my goal is to compile the qt5 port with gcc493 and the std=c++11 switch enabled.The emphasis is here on the c++11 switch, i figure if c++11 works i can use c++14 as well. Tried different things like modified the CXXFLAGS in make.conf. But it still uses c++98 I'm searching for a rock solid way to this. Thank you for the Qt Port!Dirk You can have qmake5-built ports use some custom c++ flags by modifying the qmakespecs which are by default installed into /usr/local/lib/qt5/mkspecs by the devel/qmake5 port. The name to be set is called QMAKE_CXXFLAGS, and there's no specific place for it, though you will likely have to put it somewhere referenced by freebsd-g++.conf. To build devel/qmake5 itself using c++11/14 support, adding .if (!empty(.CURDIR:M*devel/qmake5*)) CXXFLAGS+= -std=c++1y .endif to /etc/make.conf works over here - of cause, you can just extend CXXFLAGS in make.conf for your qmake5 consumers instead of using the makespecs, too. AFAIK - unlike on Windows OS, or rather, Visual C++ - FreeBSD's c++98 binaries are ABI compatible to their c++11 built counterparts, and even linked to the same STL implementation, so I don't think there's a point of using c++11 compiler mode unless the code actually uses c++11. If some consumer port specifies pedantic compilation mode, requesting c++11 or 14 might even break the build. Alonso pgpybdbmNtx6I.pgp Description: PGP signature ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
[kde-freebsd] Qt 5 and GCC4.9.3
Hello, I'm using Freebsd 9 (current FreeNAS) and my goal is to compile the qt5 port with gcc493 and the std=c++11 switch enabled.The emphasis is here on the c++11 switch, i figure if c++11 works i can use c++14 as well. Tried different things like modified the CXXFLAGS in make.conf. But it still uses c++98 I'm searching for a rock solid way to this. Thank you for the Qt Port!Dirk ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
[kde-freebsd] Qt 5 ports
Folks, I think Qt5 ports are usable enough and can be committed to ports. We may missing some bits, but we'll find it sooner :) Thoughts? Max ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5 ports
Hi Go for it, it's high time to get it out in the open. mfg Tobias 2014-02-26 10:12 GMT+01:00 Max Brazhnikov m...@freebsd.org: Folks, I think Qt5 ports are usable enough and can be committed to ports. We may missing some bits, but we'll find it sooner :) Thoughts? Max ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
rc1 brings some changes to the installation layout. Most notable ones: versioned libraries and pkg-config files, and sandboxed binaries. A wrapper will be released to be installed in bin/, and will wrap all Qt 3-5 user binaries (not those in libexec/, then). I've tried to stick to the default configuration (except for libexecdir, which would be lib/qt5/libexec/), but I'd like you guys to review it. If anyone is aware of a better place for -bindir than lib/qt5/bin/, please tell me; bin/qt5/ puts qt5 in shell completion, otherwise would be nice. -prefix /usr/local -bindir /usr/local/lib/qt5/bin -headerdir /usr/local/include/qt5 -libdir /usr/local/lib -plugindir /usr/local/lib/qt5/plugins -importdir /usr/local/lib/qt5/imports -datadir /usr/local/share/qt5 -docdir /usr/local/share/doc/qt5 -translationdir /usr/local/share/qt5/translations -sysconfdir /usr/local/etc/xdg -archdatadir /usr/local/lib/qt5 -libexecdir /usr/local/libexec/qt5 -qmldir /usr/local/lib/qt5/qml -examplesdir /usr/local/share/examples/qt5 -testsdir /usr/local/share/qt5/tests As a side note, mkspecs are now installed into lib/qt5/mkspecs/. I'm not very happy with this, so I've thought about changing archdatadir to be the same as datadir, but I think it's better to adhere to Qt defaults here. Comments welcome. To make easier to change this paths, plists will be using only QT_* variables. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
On Wed, 5 Dec 2012 01:46:57 +0100, Alberto Villa wrote: On Fri, Nov 16, 2012 at 12:25 AM, Max Brazhnikov m...@issp.ac.ru wrote: 2) iconengines, imageformats, inputmethods could be merged into qt-runtime This is a bit tricky, because of splitted tarballs. Here is what I plan to do: - install ICO, JPEG and GIF imageformats along with qt5-gui (only added dependency is libjpeg); - install inputmethods (which I suppose is now platforminputcontexts) along with qt5-gui (no additional dependency); - install SVG imageformat and iconengine along with qt5-svg (as per tarball layout); - create a qt5-imageformats port for additional plugins (which have their own tarball). Does it sound good? Great! As you may have seen, I've also packed PlatformSupport and generic/XCB platform plugins with qt5-gui; that's because qt5-gui won't work without one of them (XCB to be the preferred one), but since they depend on qt5-gui they can't be made a dependency of it. Another solution could be to split the XCB plugin (the only one with additional dependencies) and make the Qt gui component install it too; it would let people depend only on qt5-gui, but I don't like it. I don't think we can expect people to install the plugin on their own (a'-la Phonon), in which case stuff like kde-workspace should depend on it; not easy, I think. Similar situation for PrintSupport: I didn't split CUPS plugin in its own port for the same reason, but rather made it optional at buildtime. What's your opinion on these matters? I'm fine with either solution, buildtime options seem quite reasonable. 4) qmake-based projects are quite popular, I'm thinking about QMAKE_CONFIGURE, which will invoke 'do-configure' like editors/texmaker does. How do USE_QMAKE=[45], QMAKE_ENV and QMAKE_ARGS (in place of QMAKEFLAGS) sound? To mimic CMake stuff... All right. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
On Fri, Nov 30, 2012 at 1:52 PM, Alberto Villa avi...@freebsd.org wrote:
Qt 4 is now building fine along with Qt 5. There is still this
conflict with *.pc files, I'll take care of it.
This should be fixed upstream with the next release (rakuco@ was
pinged for FreeBSD):
http://lists.qt-project.org/pipermail/development/2012-September/006551.html
We might even end up installing libraries in ${LOCALBASE}/lib.
--
Alberto Villa, FreeBSD committer avi...@freebsd.org
http://people.FreeBSD.org/~avilla
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
On 30-11-2012 13:52, Alberto Villa wrote: Qt 4 is now building fine along with Qt 5. There is still this conflict with *.pc files, I'll take care of it. I think this is nuts, if these pkg-config files are shipped by upstream, upstream should version them. If they don't do that and we need to do it, then everything that finds QT5 with pkg-config (which might not me a lot) needs to be patched :/. That or QT5 is a drop in replacement of QT4, and looking at my experiance with GTK+ that probably not true. -Koop ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
On Fri, Nov 16, 2012 at 12:25 AM, Max Brazhnikov m...@issp.ac.ru wrote: 2) iconengines, imageformats, inputmethods could be merged into qt-runtime This is a bit tricky, because of splitted tarballs. Here is what I plan to do: - install ICO, JPEG and GIF imageformats along with qt5-gui (only added dependency is libjpeg); - install inputmethods (which I suppose is now platforminputcontexts) along with qt5-gui (no additional dependency); - install SVG imageformat and iconengine along with qt5-svg (as per tarball layout); - create a qt5-imageformats port for additional plugins (which have their own tarball). Does it sound good? As you may have seen, I've also packed PlatformSupport and generic/XCB platform plugins with qt5-gui; that's because qt5-gui won't work without one of them (XCB to be the preferred one), but since they depend on qt5-gui they can't be made a dependency of it. Another solution could be to split the XCB plugin (the only one with additional dependencies) and make the Qt gui component install it too; it would let people depend only on qt5-gui, but I don't like it. I don't think we can expect people to install the plugin on their own (a'-la Phonon), in which case stuff like kde-workspace should depend on it; not easy, I think. Similar situation for PrintSupport: I didn't split CUPS plugin in its own port for the same reason, but rather made it optional at buildtime. What's your opinion on these matters? 4) qmake-based projects are quite popular, I'm thinking about QMAKE_CONFIGURE, which will invoke 'do-configure' like editors/texmaker does. How do USE_QMAKE=[45], QMAKE_ENV and QMAKE_ARGS (in place of QMAKEFLAGS) sound? To mimic CMake stuff... -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
Qt 4 is now building fine along with Qt 5. There is still this conflict with *.pc files, I'll take care of it. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
On Fri, Nov 23, 2012 at 2:24 AM, Alberto Villa avi...@freebsd.org wrote: I'm removing DO_NOT_EXTRACT as the smaller tarballs make it useless, in my opinion. I've tried it and it doesn't give any noticeable speedup. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
I've moved discussion to kde-freebsd maillist. On Thu, 22 Nov 2012 11:58:05 +0100, Alberto Villa wrote: On Sat, Nov 17, 2012 at 3:25 PM, Alberto Villa avi...@freebsd.org wrote: In my tests -fast makes configure step a lot slower. I'll keep checking. Qt 4 and Qt 5 are a bit different on this. I think I got to the best possible solution: run configure without -fast (which just creates stub Makefiles for examples, tests, and similar) and then run QMake (recursively, so no QMake is invoken in build stage) in BUILD_WRKSRC; it results in a much faster configure stage compared to Qt 4. Great! I also wonder what you'd like to include in the moc+uic... port. The src/tools/ directory contains moc, uic, rcc, qdoc, qdbuscpp2xml and qdbusxml2cpp. Only those which are frequently used together and don't have any dependency on qt libraries: moc, uic, rcc are good candidates. I would avoid a qt5-tools with all of them as it would uselessly depend on D-Bus; maybe a qt5-buildtools with moc, uic and rcc, and a qt5-qdoc for qdoc only? yes, sounds good. Also, I see that we don't have a port for qdbus*2*; should we make one? I suppose yes, although nobody complains about lack of them. In the process, I'm removing as most hacks as possible; more on this when I commit something worth to see (tonight, probably). Qt 4 will be broken for a while, as I'll try to backport some of the improvements. wouldn't qt.mk be overloaded bearing both qt4 and qt5? You could start with new file for qt5, we'll merge them later or backport changes to qt4. Max ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
On Thu, Nov 22, 2012 at 8:08 PM, Alberto Villa avi...@freebsd.org wrote:
On Thu, Nov 22, 2012 at 7:41 PM, Max Brazhnikov m...@freebsd.org wrote:
wouldn't qt.mk be overloaded bearing both qt4 and qt5? You could start
with new file for qt5, we'll merge them later or backport changes to qt4.
That was my idea, but I dropped it almost immediately as I managed to
merge the two versions pretty nicely, with just few .if
${_QT_VERSION:M4*} for compatibility. I'll commit the changes very
soon, so you'll be able to review and the discussion can move forward.
Just for the records, I found more difficult to create a whole new
file rather than cleaning up bsd.qt.mk.
--
Alberto Villa, FreeBSD committer avi...@freebsd.org
http://people.FreeBSD.org/~avilla
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information
Re: [kde-freebsd] Qt 5
Quick note to say that those interested in Qt 5 porting should read incoming commit logs; they have information also on the first, messy commit. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
