CMake policies issues was: Re: kdesupport/automoc

Patrick Spendrin ps_ml at gmx.de
Thu Jun 24 23:07:00 CEST 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 24.06.2010 22:50, schrieb 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?

That is another dependency that is required only because of lazyness (of
fixing the bugs in the first place).

> 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?

These packages are not ready atm for development from packages (I still
hear voices saying KDE4Workspace is not for Windows at all). Strigi and
some other packages have already been fixed, so I would rather see all
packages fixed instead of loosing this possibility.

> 
>>> 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,
Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (MingW32)

iEYEARECAAYFAkwjyPQACgkQi49rfdk/G3YeTACfTttXdih8he6tWmIs2HhNCwmA
QEAAn3tYk6Gqda5fC7ccgT+KfmZOXMNg
=PyVp
-----END PGP SIGNATURE-----


More information about the Kde-buildsystem mailing list