Review Request 118512: RFC: Rename CMake configuration files to KFileMetaData5*

[Vishesh Handa]

> On June 11, 2014, 1:51 p.m., Aleix Pol Gonzalez wrote:
> > Ship It!

Uhh. Currently the patch renames it to KFileMetaData5 instead of KF5::FileMetaData. We want the one with the KF5, not this on.


- Vishesh


-----------------------------------------------------------
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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140611/936b2831/attachment.html>