CMake policies issues was: Re: kdesupport/automoc

[Alexander Neundorf]

On Thursday 24 June 2010, Maciej Mrozowski wrote:
> On Thursday 24 of June 2010 22:30:57 Alexander Neundorf wrote:
> > On Thursday 24 June 2010, Maciej Mrozowski wrote:
> > > On Wednesday 23 of June 2010 23:00:12 Alexander Neundorf wrote:
> > > > On Tuesday 22 June 2010, Alexander Neundorf wrote:
> > > >
> > > > Ok, I added cmake_policy(PUSH/POP) to Automoc4Config.cmake, so any
> > > > policy changes done inside there don't propagate to the outside, so
> > > > CMP0002 is not reset to NEW, so the duplicated target names should be
> > > > ok. Let me know if there are still problems.
> > >
> > > While we're at it, would be something like attached patch more
> > > reliable? So not to rely on find_program or get_filename_component to
> > > aquire automoc4 path, instead to use CMAKE_INSTALL_PREFIX/bin/automoc4
> > > directly. I mean, at the time Automoc4Config is prepared, we already
> > > know exactly where is automoc4 executable located.
> >
> > On Unix systems, typically, yes.
> > On Windows, no.
> > They want to be able to install it to a location chosen by the user at
> > package-install time, which can be different from CMAKE_INSTALL_PREFIX
> > chosen at cmake time.
> > So finding the executable based on the own location has its advantages. I
> > wouldn't change this now.
>
> How about they run sed on Automoc4Config.cmake?

Usually sed doesn't exist on a normal Windows box.

> Also what I see is, any <module>Config.cmake file I have here
> (KdepimLibsConfig.cmake, KDE4WorkspaceConfig.cmake, AkonadiConfig.cmake)
> contains hardcoded (determined at cmake time) paths.

This may be, but more flexible is better. So I really wouldn't change this.

> Only KDevPlatformConfig.cmake seems to be more flexible and contains the
> following:
>
> <snip>
> get_filename_component(_KDEVPLATFORM_CURRENT_DIR 
> "${CMAKE_CURRENT_LIST_FILE}" PATH)
>
> if(NOT WIN32)
> # This is needed on non-win32 platforms, as lib-install-dir might be in a
> # totally different prefix than include-install-dir. So instead hardcode
> the # absolute path during buildtime
> set( KDEVPLATFORM_INCLUDE_DIR "/usr/include/kdevplatform" )
>
> else(NOT WIN32)
>
> set( KDEVPLATFORM_INCLUDE_DIR
> "${_KDEVPLATFORM_CURRENT_DIR}/../../../include/kdevplatform" )
>
> endif(NOT WIN32)
> </snip>
>
> How windows guys deal with this there?

I think at least they are unhappy with it.
Will you be at Akademy ?

> > > I've also moved Automoc config files from <libdir>/automoc4 to
> > > <libdir>/cmake/Automoc4 to decrease namespace pollution and to keep it
> > > consistent with kdelibs/kdevplatform/kdeworkspace/soprano (it requires
> > > cmake 2.6.3 I think).
> >
> > Hmm, no real objections here, as long as you also take care if later on
> > somebody has problems with this nevertheless ;-)
>
> Unfortunately install location cannot be changed to <libdir>/cmake/ when
> find_program(AUTOMOC4_EXECUTABLE automoc4 PATHS  "${_AUTOMOC4_BIN_DIR}/bin"
> NO_DEFAULT_PATH) is being used, especially with NO_DEFAULT_PATH.

Why ? I mean, when getting the directory of course we would have to go one 
level more up.

> Also I question. FindAutomoc4.cmake says:
> find_package_handle_standard_args(Automoc4 "Did not find automoc4 (part of
> kdesupport). Searched for Automoc4Config.cmake in ${AUTOMOC4_SEARCH_PATHS}
> using suffixes automoc4 lib/automoc4 lib64/automoc4." AUTOMOC4_EXECUTABLE)
>
> But AUTOMOC4_SEARCH_PATHS is nowhere specified, especially not as
> alternative lookup location to find_program(AUTOMOC4_EXECUTABLE, is this a
> bug or some internal behaviour to look at <variable>_SEARCH_PATHS ?

This was a leftover, I reomved it now. 

Thanks
Alex