[kde-doc-english] Review Request 115077: Rename Macros in KF5DocTools to KDE5_

[Luigi Toscano]

> On Jan. 17, 2014, 6:51 p.m., Alex Merry wrote:
> > KF5DocToolsMacros.cmake, lines 166-172
> > <https://git.reviewboard.kde.org/r/115077/diff/1/?file=234284#file234284line166>
> >
> >     These should *not* be renamed, as they are compatibility macros.  However, they should probably be moved to kde4support.
> 
> Aleix Pol Gonzalez wrote:
>     I wouldn't rename it indeed.
>     
>     Moving it to KDE4Support can be good indeed, although it kind of defeats the purpose, as you'll need to actually depend on KDE4Support to get the warning.
> 
> David Narváez wrote:
>     Luigi, your call.
> 
> Alex Merry wrote:
>     Well, most projects will start off depending on KDE4Support anyway, and if you don't use it I think you should just get an error about the macro not being found.
> 
> Luigi Toscano wrote:
>     My thoughts:
>     - is the dependency on KDE4Support the first thing a ported application should do? If yes, then the macros can be kept and moved; but please read on;
>     - KDE4_CREATE_HTML_HANDBOOK can be completely removed. It has been deprecated on Wed Aug 15 03:55:48 2007 +0000, 82f7b6ba0f8be7d314ac780b9a873e98b6be39b2, and it is not used (apart from the definition in kdelibs and kf5/kdoctools).
>     - KDE4_CREATE_HANDBOOK should not be renamed, and it can be moved to KDE4Support (I see that it was already renamed as KDOCTOOLS_CREATE_HANDBOOK in the frameworks-based code)
>     - I see KDE4_SERIALIZE_TOOL has been renamed as well; but it is defined in KDE4Support:
>     http://lxr.kde.org/source/frameworks/kde4support/cmake/modules/FindKDE4Internal.cmake#455
>     I'm not sure how to deal with this: probably it would be better to define it here and rename it as KDOCTOOLS_blabla.
>     
>     Does it make sense?
> 
> Alex Merry wrote:
>     In general, yes, the first thing a ported application will do is replace the lines to search for kdelibs4 with lines to find KDE4Support (and other frameworks).
>     
>     I agree that KDE4_CREATE_HTML_HANDBOOK should be removed (along with any other macro that didn't actually do anything in kdelibs4).  If KDE4_CREATE_HANDBOOK was a useful macro in kdelibs4, it should move to kde4support (and either be defined as it is here, or forward to KDOCTOOLS_CREATE_HANDBOOK).
>     
>     I have no idea how the KDE4_SERIALIZE_TOOL thing is supposed to work, so I can't comment on that.

KDE4_SERIALIZE_TOOL is used only here (kdoctools); I suggest to rename it as KDOCTOOLS_SERIALIZE_TOOL and add its definition (see http://lxr.kde.org/source/kde/kdelibs/cmake/modules/FindKDE4Internal.cmake#721).

KDE4_CREATE_HANDBOOK is used everytime there is documentation in kdelibs4-based applications, so yes, we need to keep it somehow for migration purposes :)


- Luigi


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115077/#review47592
-----------------------------------------------------------


On Jan. 18, 2014, 1:16 p.m., David Narváez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115077/
> -----------------------------------------------------------
> 
> (Updated Jan. 18, 2014, 1:16 p.m.)
> 
> 
> Review request for Documentation, KDE Frameworks and Luigi Toscano.
> 
> 
> Repository: kdoctools
> 
> 
> Description
> -------
> 
> Part of the overall task of removing mentions of KDE4 from the code.
> 
> 
> Diffs
> -----
> 
>   KF5DocToolsMacros.cmake 191a2c5 
> 
> Diff: https://git.reviewboard.kde.org/r/115077/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> David Narváez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-doc-english/attachments/20140119/08183b68/attachment.html>