KDE/kdelibs/cmake/modules

[Andreas Pakulat]

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 at kde.org
> > CCMAIL: neundorf at 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.