cmake problem on win32

[Ralf Habacker]

Alexander Neundorf schrieb:
> On Thursday 23 October 2008, you wrote:
>   
>> Alexander Neundorf schrieb:
>>     
>>> On Wednesday 22 October 2008, Christian Ehrlicher wrote:
>>>       
>>>> Andreas Pakulat schrieb:
>>>>         
>>>>> On 21.10.08 22:48:39, Andreas Pakulat wrote:
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> I've got a small problem here with using INCLUDE_INSTALL_DIR during
>>>>>> cmake time. It seems as if that variable is set to "include" instead
>>>>>> of an absolute path. This causes a problem with kdevplatform, because
>>>>>> that variable is used to write a KDevPlatformConfig.cmake with the
>>>>>> right include-dir.
>>>>>>
>>>>>> This file now ends up with
>>>>>>
>>>>>> set(KDevPlatform_INCLUDE_DIR "include/kdevplatform")
>>>>>>
>>>>>> which of course doesn't work.
>>>>>>
>>>>>> Everything is fine on linux, it only breaks on windows.
>>>>>>
>>>>>> KDevPlatformConfig.cmake.in looks like this:
>>>>>>
>>>>>> set(KDevPlatform_INCLUDE_DIR "@INCLUDE_INSTALL_DIR@/kdevplatform")
>>>>>>             
>>>>> Apparently the reason is FindKDE4Internal.cmake. On Win32 it sets the
>>>>> variable to just "include", while on other platforms it also prepends
>>>>> CMAKE_INSTALL_PREFIX. This seems to happen for all other variables set
>>>>> there as well, is this intentional? Can it be changed to be the same on
>>>>> all platforms? I'd like to avoid the extra check in KDevPlatform if
>>>>> possible.
>>>>>           
>>>> Where does INCLUDE_INSTALL_DIR come from? You can't know where the user
>>>> installs your app in the end so using INCLUDE_INSTALL_DIR on windows
>>>> isn't a good idea at all.
>>>>         
>>> Yes.
>>> The FOO_INSTALL_DIR variables are the install destination of the current
>>> project, they don't have to match with anything else already installed.
>>>
>>> KDE4_LIB_DIR and KDE4_INCLUDE_DIR are the locations where kdelibs has
>>> been installed to and are determined by FindKDE4Internal.cmake
>>> (FOO_INSTALL_DIR are just initialized by FindKDE4Internal.cmake,
>>> (basically) independent from any already installed things).
>>>
>>> So the code above is actually correct (except the relative directory).
>>> For a project _using_ KDevPlatform KDevPlatform_INCLUDE_DIR will be what
>>> INCLUDE_INSTALL_DIR was while building KDevPlatform.
>>>
>>> On Windows FOO_INSTALL_DIR are relative directories because of what
>>> Christian said, the user can install them anywhere. I think it was Ralph
>>> who was working on this.
>>> Have a look at kdelibs/CreateKDELibsDependenciesFile.cmake.
>>> There is a macro MAKE_INSTALL_PATH_ABSOLUTE(), which converts relative
>>> paths to absolute ones. Not really. it prefixes them with the _variable_
>>> KDE4_INSTALL_DIR (note that the $ is escaped). Then KDE4_INSTALL_DIR is
>>> set like this:
>>> if (NOT KDE4_INSTALL_DIR)
>>>    set(KDE4_INSTALL_DIR         \"${CMAKE_INSTALL_PREFIX}\")
>>> endif (NOT KDE4_INSTALL_DIR)
>>>
>>> I.e. the install locations are still somewhat flexible (but it doesn't
>>> seem completely finished yet).
>>>       
>> what do you think is required to finish it completly  ? - I remember the
>> most annoying problem in this area was that export_library_dependencies
>> wrotes absolute pathes and was not able to create variable based
>> dependencies.  Second it was impossible to patch the output  from
>> export_library_dependencies at configure time to make those dependencies
>> variable by hand.
>>     
>
> I want to try the new "exported targets" feature of cmake 2.6, which should 
> help here.
>
> How do you handle it currently ?
> On my system (Linux) KDELibsDependencies.cmake looks like:
>
> if (NOT KDE4_INSTALL_DIR)
>    set(KDE4_INSTALL_DIR         "/opt/kde4-cmake-HEAD")
> endif (NOT KDE4_INSTALL_DIR)
>
> set(KDE4_LIB_INSTALL_DIR     "/opt/kde4-cmake-HEAD/lib")
> set(KDE4_LIBEXEC_INSTALL_DIR "/opt/kde4-cmake-HEAD/lib/kde4/libexec")
> set(KDE4_INCLUDE_INSTALL_DIR "/opt/kde4-cmake-HEAD/include")
> ...
>
> On a windows machine it should look like:
>
> if (NOT KDE4_INSTALL_DIR)
>    set(KDE4_INSTALL_DIR         "/opt/kde4-cmake-HEAD")
> endif (NOT KDE4_INSTALL_DIR)
>
> set(KDE4_LIB_INSTALL_DIR     "${KDE4_INSTALL_DIR}/lib")
> set(KDE4_LIBEXEC_INSTALL_DIR "${KDE4_INSTALL_DIR}/lib/kde4/libexec")
> set(KDE4_INCLUDE_INSTALL_DIR "${KDE4_INSTALL_DIR}/include")
> ...
>
> Is this correct ?
>   
yes
> What do you do on installing ?
> Do you patch the "set(KDE4_INSTALL_DIR ...)" line to match the actual install 
> location ?
>   
yes, see kdelibs/cmake/modules/FindKDE4Internals.cmake line 439
....
      # on win32 the install dir is determined on runtime not install time
      # KDELIBS_INSTALL_DIR and QT_INSTALL_DIR are used in 
KDELibsDependencies.cmake to setup
      # kde install paths and library dependencies
      get_filename_component(_DIR ${KDE4_KDECONFIG_EXECUTABLE} PATH )
      get_filename_component(KDE4_INSTALL_DIR ${_DIR} PATH )
      get_filename_component(_DIR ${QT_QMAKE_EXECUTABLE} PATH )
      get_filename_component(QT_INSTALL_DIR ${_DIR} PATH )
   endif (WIN32)

The problem are currently the dependencies in the generated file 
KDELibsDependenciesInternals.cmake like

  SET("threadweaver_LIB_DEPENDS" 
"E:/daten/kde/emerge-msvc-root/lib/QtCored4.lib;")

or this
  SET("E:/daten/kde/emerge-msvc-root/lib/QtUiTools.lib_LINK_TYPE" 
"optimized")

They are hardcoded but should use ${QT_:INSTALL_DIR} in case of qt 
libraries and ${KDE4_INSTALL_DIR} for the rest (for now).

Ralf