[kde-freebsd] Qt 5 ports

2014-02-26 Thread Max Brazhnikov
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 htt

Re: [kde-freebsd] Qt 5

2012-11-22 Thread Max Brazhnikov
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 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 go

Re: [kde-freebsd] Qt 5

2012-11-22 Thread Alberto Villa
On Thu, Nov 22, 2012 at 7:41 PM, Max Brazhnikov 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

Re: [kde-freebsd] Qt 5

2012-11-22 Thread Alberto Villa
On Thu, Nov 22, 2012 at 8:08 PM, Alberto Villa wrote: > On Thu, Nov 22, 2012 at 7:41 PM, Max Brazhnikov 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

Re: [kde-freebsd] Qt 5

2012-11-22 Thread Alberto Villa
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 http://people.FreeBSD.org/~avilla ___ kde-freebsd mailing list kde-freebs

Re: [kde-freebsd] Qt 5

2012-11-22 Thread Alberto Villa
A couple more notes. Plists are being updated, but they're not guaranteed to be correct. I'm still doing the job in chroot on my laptop, Tinderbox will come. I'm removing DO_NOT_EXTRACT as the smaller tarballs make it useless, in my opinion. -- Alberto Villa, FreeBSD committer http://people.Free

Re: [kde-freebsd] Qt 5

2012-11-23 Thread Alberto Villa
On Fri, Nov 23, 2012 at 2:24 AM, Alberto Villa 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 http://people.FreeBSD.org/~avilla __

Re: [kde-freebsd] Qt 5

2012-11-30 Thread Alberto Villa
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 http://people.FreeBSD.org/~avilla ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mai

Re: [kde-freebsd] Qt 5

2012-12-04 Thread Alberto Villa
On Fri, Nov 16, 2012 at 12:25 AM, Max Brazhnikov 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

Re: [kde-freebsd] Qt 5

2012-12-05 Thread Alberto Villa
On Fri, Nov 30, 2012 at 1:52 PM, 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. This should be fixed upstream with the next release (rakuco@ was pinged for FreeBSD): http://lists.qt-project.org/pipermail/deve

Re: [kde-freebsd] Qt 5

2012-12-05 Thread Koop Mast
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 d

Re: [kde-freebsd] Qt 5

2012-12-05 Thread Alberto Villa
On Wed, Dec 5, 2012 at 2:19 PM, Koop Mast wrote: > 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

Re: [kde-freebsd] Qt 5

2012-12-05 Thread Koop Mast
On 5-12-2012 13:58, Alberto Villa wrote: On Fri, Nov 30, 2012 at 1:52 PM, 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. This should be fixed upstream with the next release (rakuco@ was pinged for FreeBSD): ht

Re: [kde-freebsd] Qt 5

2012-12-06 Thread Max Brazhnikov
On Wed, 5 Dec 2012 01:46:57 +0100, Alberto Villa wrote: > On Fri, Nov 16, 2012 at 12:25 AM, Max Brazhnikov 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

Re: [kde-freebsd] Qt 5

2012-12-10 Thread Alberto Villa
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 confi

Re: [kde-freebsd] Qt 5 ports

2014-02-26 Thread T.C.Berner
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 : > 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] Qt 5 and GCC4.9.3

2015-05-21 Thread Dirk Niebelus
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

Re: [kde-freebsd] Qt 5 and GCC4.9.3

2015-05-21 Thread Schaich Alonso
On Wed, 20 May 2015 08:03:40 + (UTC) Dirk Niebelus 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. > >