> On June 11, 2014, 1:51 p.m., Aleix Pol Gonzalez wrote: > > Ship It! > > Vishesh Handa wrote: > Uhh. Currently the patch renames it to KFileMetaData5 instead of > KF5::FileMetaData. We want the one with the KF5, not this on.
Heh true :$. - Aleix ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118512/#review59795 ----------------------------------------------------------- On June 4, 2014, 6:28 a.m., Matthew Dawson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118512/ > ----------------------------------------------------------- > > (Updated June 4, 2014, 6:28 a.m.) > > > Review request for Plasma, Jonathan Riddell and Vishesh Handa. > > > Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334 > > http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334 > > > Repository: kfilemetadata > > > Description > ------- > > I've posted this RR as an RFC about the general structure of this idea. I > just choose KFileMetaData as that is what my package manager conflicted over > first. Ideally I want to push this change to any needed repositories for > Plasma Next. > > As far as I understand the ability for Plasma Next and KDE4 application to be > co-installed, all libraries should be co-installable except as listed on this > page: http://community.kde.org/Plasma/Coinstallability . However, on source > based distributions, such as Gentoo, to have both the KDE4 and KF5 versions > simultaneously installed requires that the development files are also > co-installable. As mentioned on this Gentoo bug[1], the header files are > trivially dealt with, and the library simlink will probably be a downstream > specific solution (as CMake doesn't require it for compiling). However, the > CMake configuration files are another matter. This is take one of trying to > fix this issue. If a different naming scheme, or if some different CMake > trickery is desired I'll see about changing things to that, otherwise I think > this is the simple and easy solution. > > I also volunteer to go through all the dependent packages and have patches > ready (as best as I am able), as well as fix up any build failures that occur > due to this change. Only find_package calls need modification, targets are > left alone. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=512334 > > > Diffs > ----- > > src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c > KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 > CMakeLists.txt aa2b0864ca8b2126ffcabf5cbad28b06dbb682b2 > > Diff: https://git.reviewboard.kde.org/r/118512/diff/ > > > Testing > ------- > > Tested compiling Baloo against a system install with this patch applied. > Baloo sucessfully linked against the KF5 version and all Baloo tests ran to > completion. > > All KFileMetaData unit tests passed too ;) > > > Thanks, > > Matthew Dawson > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
