On Thu, Jun 8, 2017 at 12:27 AM, Albert Astals Cid <aa...@kde.org> wrote: > El dissabte, 3 de juny de 2017, a les 11:49:00 CEST, Volker Krause va > escriure: >> On Thursday, 25 May 2017 12:33:49 CEST Volker Krause wrote: >> > On Tuesday, 23 May 2017 18:31:35 CEST Aleix Pol wrote: >> > > I would have looked into fixing it, but I'm not sure I understand why >> > > there's all the RPATH logic in place, so I'd prefer to hear from you >> > > first. >> > >> > I have removed the remains of the pre-ECM rpath handling. This also >> > changed >> > binary output directories on Linux to follow KDE standards, so you might >> > want to do a clean build to avoid issues with outdated binaries in the >> > build dir. >> > >> > > A good next step would also be to get it running on build.kde.org, so >> > > we can identify these issues. >> > >> > Indeed, I've requested CI coverage now. >> >> Looks like in order to get CI coverage we need to move to kdereview (which >> is fine, I think it's ready for that), but that requires to know where this >> should end up afterwards. >> >> I guess the candidates are extragear/libs or frameworks? frameworks seems >> conceptually like the right place, but putting something there that is still >> fairly new and has seen little field testing seems sub-optimal. Opinions? > > To me it seems a few releases from extragear would make sense before moving to > frameworks and promise full API/ABI compatibility. > > OTOH when moving from extreagear to frameworks we may have to rename library > (to have the KF5 suffix) which would break also API (at least at the cmake > level). > > How do people feel having libs in extreager having the KF5 "cmake naming" in > the understanding that we're stabilizing them to be part of frameworks > eventually?
IMO it's a bit weird and unsettling. But then, we're already doing it for many pim libraries (not in extragear but in applications, still not part of KF5). Aleix
