CMake policies issues was: Re: kdesupport/automoc

[Maciej Mrozowski]

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?
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. 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'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.
Anyway the way automoc4 is being located now leaves us no option but to 
install Automoc4Config.cmake directly in <libdir>/autoconf.

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 ?

-- 
regards
MM