> 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. > > Luigi Toscano wrote: > 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 :) > > David Narváez wrote: > I'll split this RR into several others covering those changes.
Doesn't that serialization tool sound more like ECM? It could be useful if you need to serialize any kind of build. - David ----------------------------------------------------------- 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
