KDE/kdelibs/cmake/modules

[Alexander Neundorf]

Hi,

we have a patch regarding Soprano. It's already in trunk, and by still getting 
this into 4.3.0 we can hopefully avoid compatiblity issues later on.
CMakeLists.txt using soprano right now do 
include(SopranoAddOntology.cmake)
so that file must be somewhere in CMAKE_MODULE_PATH, and stay there, and also 
with that name. The patch makes that unnecessary and moves the include to 
FindSoprano.cmake, so it is nicely encapsulated and can potentially be 
changed later on.

On Thursday 30 July 2009, Sebastian Trüg wrote:
> On Wednesday 29 July 2009 22:36:17 Alexander Neundorf wrote:
> > Hi Sebastian,
> >
> > > --- trunk/KDE/kdelibs/cmake/modules/FindSoprano.cmake #1004263:1004264
> > > @@ -47,18 +47,6 @@
> > >      ${KDE4_INCLUDE_DIR}
> > >      )
> > >
> > > -  # find the cmake macro file installed by soprano, relative to the
> > > include dir -  get_filename_component(_SOPRANO_PREFIX
> > > ${SOPRANO_INCLUDE_DIR} PATH) -  # first check in
> > > <prefix>/share/soprano/cmake, if it's not found there, check in
> > > <prefix>/share/apps/cmake/modules -  # find_file(_SOPRANO_MACRO_FILE
> > > NAMES SopranoAddOntology.cmake HINTS
> > > ${_SOPRANO_PREFIX}/share/soprano/cmake ) -
> > > find_file(_SOPRANO_MACRO_FILE NAMES SopranoAddOntology.cmake HINTS
> > > ${_SOPRANO_PREFIX}/share/apps/cmake/modules ) -
> > > -  # since which version of soprano is this file installed ?
> > > -  # we should fail if the file is not found but SOPRANO_MIN_VERSION is
> > > bigger than this version. -  if(_SOPRANO_MACRO_FILE)
> > > -    include(${_SOPRANO_MACRO_FILE})
> > > -  endif(_SOPRANO_MACRO_FILE)
> > > -
> > >    find_library_with_debug(SOPRANO_INDEX_LIBRARIES
> > >      WIN32_DEBUG_POSTFIX d
> > >      NAMES
> > > @@ -186,6 +174,23 @@
> > >        set(_plugins "${_plugins} virtuosobackend")
> > >      endif(EXISTS ${SOPRANO_PLUGIN_DIR}/virtuosobackend.desktop)
> > >
> > > +    # make sure the Soprano cmake macros are found
> > > +    # We also include it directly for convinience
> > > +    get_filename_component(_SOPRANO_PREFIX ${SOPRANO_INCLUDE_DIR}
> > > PATH) +    find_file(_SOPRANO_MACRO_FILE NAMES SopranoAddOntology.cmake
> > > HINTS ${_SOPRANO_PREFIX}/share/soprano/cmake ) +   
> > > if(_SOPRANO_MACRO_FILE) +      # new Soprano > 2.3.0 location
> > > +      include(${_SOPRANO_MACRO_FILE})
> > > +      set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
> > > ${_SOPRANO_PREFIX}/share/soprano/cmake) +    else(_SOPRANO_MACRO_FILE)
> > > +      # the old Soprano 2.3.0 location
> > > +      find_file(_SOPRANO_MACRO_FILE_OLD NAMES SopranoAddOntology.cmake
> > > HINTS ${_SOPRANO_PREFIX}/share/apps/cmake/modules ) +
> > > if(_SOPRANO_MACRO_FILE_OLD)
> > > +        include(${_SOPRANO_MACRO_FILE_OLD})
> > > +        set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
> > > ${_SOPRANO_PREFIX}/share/apps/cmake/modules) +
> > > endif(_SOPRANO_MACRO_FILE_OLD)
> > > +    endif(_SOPRANO_MACRO_FILE)
> > > +
> > >    endif(Soprano_FOUND)
> > >
> > >    if(Soprano_FOUND)
> >
> > I think this looks good.
> > Although it's a bit ugly to add that directory to CMAKE_MODULE_PATH, it's
> > probably necessary.
>
> yes, I think so, too. The only other possibility would be to include the
> macro in KDE.

You mean FindSoprano.cmake could actually just include the macro ?
I wouldn't object.

> > Can you still add the include()-commands to the FindSoprano.cmake to the
> > 4.3 branch and remove the extra, now unnecessary include()-commands in
> > the CMakeLists.txt of soprano-using apps there ?
>
> Sure, I can do that. :)
> I thought it would be better to only do that in trunk and leave 4.3 as much
> unchanged as possible.

Yes, sure, but it would be even nicer if we would have 4.3.0 without these 
include()s.

> > Can you try to get the 4.3.0 tag moved for these files ?
>
> It is already tagged? Hm, I would not know how to do that except maybe
> commiting the changes to the tag, too.

I guess we'd have to contact the release team.

> > Do you know if there are users outside svn KDE/ ?
>
> I don't know.
>
> > If not, and if these issues can still be fixed in time, is the
> > modification of CMAKE_MODULE_PATH actually necessary ?
>
> Well, I mostly wanted it to work in 4.3 and did not see the big issue with
> modifying the module path.

Changing CMAKE_MODULE_PATH can change which files are found, also which 
directories are preferred before others. So changing this can lead to 
compatibility problems (as we are seeing right now).
I still think changing CMAKE_MODULE_PATH for the modules installed by kdelibs 
is ok, but in general we should try to avoid such things.

Alex