On 04.10.09 17:31:38, Alexander Neundorf wrote: > On Saturday 03 October 2009, Andreas Hartmetz wrote: > > SVN commit 1031058 by ahartmetz: > > > > Fix / adapt to FindQt4.cmake changes. Found the error in kdenetwork which > > uses reeeally old ui files. > > CCMAIL: kde-buildsystem@kde.org > > CCMAIL: neund...@kde.org > > > > > > M +1 -1 KDE4Macros.cmake > > > > > > --- trunk/KDE/kdelibs/cmake/modules/KDE4Macros.cmake #1031057:1031058 > > @@ -159,7 +159,7 @@ > > #usage: KDE4_ADD_UI3_FILES(foo_SRCS ${ui_files}) > > macro (KDE4_ADD_UI3_FILES _sources ) > > > > - qt4_get_moc_inc_dirs(_moc_INCS) > > + qt4_get_moc_flags(_moc_INCS) > > > > Hmm, what do we do here... > qt4_get_moc_inc_dirs() and also qt4_get_moc_flags() were intended to be > internal macros, i.e. not used outside FindQt4.cmake (that's why they are not > documented). > Now there is actually a file which uses this internal macro. > So, what do we do ? > Live with the changed name and assume that the one change in KDE4Macros.cmake > is the only outside user, and for everybody else it's his own fault if he > uses internal stuff ?
IMHO: Whoever uses undocumented stuff is on his own with that. The public API of a cmake module is that part that is documented. Anything else is internal (though I guess it would help naming macro's in a way that makes this clear, like prefixing with an underscore or the name of the cmake file). Thats a rule that applies to library headers in general (not just Qt/KDE), so I think we can also apply it to the CMake files as well. Andreas -- Your business will go through a period of considerable expansion. _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem