> On June 11, 2014, 7 a.m., Vishesh Handa wrote: > > How about we change the cmake file to KF5KFileMetaDataConfig.cmake instead? > > This way there will be no conflicts, and it will be consistent with the > > rest of the frameworks as well? > > Aleix Pol Gonzalez wrote: > I agree it's the best way, the only problem being tha it's actually not a > framework, at least according to the list of frameworks and projects.kde.org. > > Vishesh Handa wrote: > Yes. But it eventually will be. > > This way it is easily co-installable, and there are fewer renames in the > future. We already have a KF5::FileMetaData alias. > > Aleix Pol Gonzalez wrote: > I'll give the shipit, because I'm aware of this being done in similar > cases. > > Please make sure everything builds when pushing this.
Sounds good, I'll rename the file. Should the library also be renamed? As Baloo also conflicts, should I rename Baloo the same way, and should its library also be renamed? Or just append a 5 to CMake file? - Matthew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118512/#review59771 ----------------------------------------------------------- On June 4, 2014, 2: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, 2: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
