Re: What to do with our default hidden visibility for symbols?

2015-08-16 Thread Alex Merry
On 2015-08-14 10:01, Jaroslaw Staniek wrote: Hi, ECM's KDECompilerSettings.cmake contains:  # Default to hidden visibility for symbols  set(CMAKE_CXX_VISIBILITY_PRESET hidden)  set(CMAKE_VISIBILITY_INLINES_HIDDEN 1) This raises a warning [1] for CMake 3.3+ and ignores this. David Faure and I

Re: Proposal to improving KDE Software Repository Organization

2015-08-16 Thread David Faure
On Monday 18 August 2014 21:54:40 Michael Pyne wrote: > > Overview of Proposed Fix > > > What we would like to do instead is the classic Comp. Sci. fix: Another layer > of indirection. > > In this case, we'd like to re-organize the `kde-build-metadata` to map to the > sa

Re: What to do with our default hidden visibility for symbols?

2015-08-16 Thread David Faure
On Friday 14 August 2015 11:01:47 Jaroslaw Staniek wrote: > > This raises a warning [1] for CMake 3.3+ and ignores this. > Don't we want to set the old policy ​CMP0063 for now? > Or even prepare for removal of ​CMP0063 (see [2])? > I know, that would not be very soon. This discussion is on-going

Jenkins-kde-ci: kdelibs KDE-4.14 latest-qt4 » Linux,gcc - Build # 13 - Still Unstable!

2015-08-16 Thread no-reply
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kdelibs%20KDE-4.14%20latest-qt4/PLATFORM=Linux,compiler=gcc/13/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sun, 16 Aug 2015 13:27:09 + Build duration: 34 min CHANGE SET Revision 150d983674e9d61e2809316e062e5d91c785560

Jenkins-kde-ci: kdelibs KDE-4.14 stable-qt4 » Linux,gcc - Build # 12 - Still Unstable!

2015-08-16 Thread no-reply
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kdelibs%20KDE-4.14%20stable-qt4/PLATFORM=Linux,compiler=gcc/12/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sun, 16 Aug 2015 13:27:09 + Build duration: 13 min CHANGE SET Revision 150d983674e9d61e2809316e062e5d91c785560

Re: Proposal to improving KDE Software Repository Organization

2015-08-16 Thread John Layt
On 16 August 2015 at 11:14, David Faure wrote: > (*) I keep finding the "division" term a bit obscure, and I wonder if this > shouldn't be > called "product" instead. I.e. matching how we release things. Nowadays we > basically have 4 products (frameworks, plasma, applications, extragear?), > pr

Re: Proposal to improving KDE Software Repository Organization

2015-08-16 Thread Michael Pyne
On Sun, August 16, 2015 17:48:59 John Layt wrote: > On 16 August 2015 at 11:14, David Faure wrote: > > (*) I keep finding the "division" term a bit obscure, and I wonder if this > > shouldn't be called "product" instead. I.e. matching how we release > > things. Nowadays we basically have 4 product

Re: Replacement for KDateTime

2015-08-16 Thread Dāvis Mosāns
2015-08-11 0:37 GMT+03:00 David Jarvie : > On Mon, August 10, 2015 11:31 am, Dāvis Mosāns wrote: >> 2015-08-10 11:34 GMT+03:00 John Layt : >>> On 9 August 2015 at 17:26, Dāvis Mosāns wrote: When I implement date/time related things I always use timestamps in UTC everywhere

Re: Proposal to improving KDE Software Repository Organization

2015-08-16 Thread David Faure
On Sunday 16 August 2015 13:51:29 Michael Pyne wrote: > There's no reason even with our current build metadata that we'd *have* to > have project hierarchies, as long as each underlying git repository name > remains unique. It might even make things easier since there would be no way > for a sub

Re: Proposal to improving KDE Software Repository Organization

2015-08-16 Thread Luigi Toscano
David Faure ha scritto: > On Sunday 16 August 2015 13:51:29 Michael Pyne wrote: >> There's no reason even with our current build metadata that we'd *have* to >> have project hierarchies, as long as each underlying git repository name >> remains unique. It might even make things easier since there

Re: Proposal to improving KDE Software Repository Organization

2015-08-16 Thread Allen Winter
On Sunday, August 16, 2015 11:21:00 PM David Faure wrote: > On Sunday 16 August 2015 13:51:29 Michael Pyne wrote: > > There's no reason even with our current build metadata that we'd *have* to > > have project hierarchies, as long as each underlying git repository name > > remains unique. It migh