Do we need KDEWIN_DIR as an environment variable? - was: Re: KDE/kdelibs/cmake/modules

[Christian Ehrlicher]

Saro Engels schrieb:
> Alexander Neundorf schrieb:
>> On Sunday 23 December 2007, Saro Engels wrote:
>>> Ralf Habacker schrieb:
>>>> Andreas Pakulat schrieb:
>>>>> SVN commit 751844 by apaku:
>>>>>
>>>>> Don't require FindKDEWIN to succeed, its just a convenience thing to
>>>>> not have to set CMAKE_INCLUDE_PATH and CMAKE_LIB_PATH when installing
>>>>> gnuwin32 libs into a "known" place (like C:\Program Files\win32libs).
>>>>> But that breaks things like emerge which already set the two variables
>>>>> and thus don't set KDEWIN_DIR and don't need to set it.
>>>>>
>>>>> If the convenience thing isn't needed FindKDEWIN.cmake can be removed
>>>>> completely
>>>> This would mean to exclude application developers using kdewin-installer
>>> No - the point is the following:
>>> I cannot see any difference between the kdesupport libraries (strigi,
>>> eigen, soprano etc.) and the gnuwin32 libraries except for the source of
>>> the package. Libraries are libraries whereever they come from.
>>>
>>> So basically the idea behind the gnuwin32/kdewin directory is to be able
>>> to use libraries and header files from different directories than the
>>> kderoot directory. That should not be limited to one directory and then
>>> hardcoded within the kde sources - If we have to decide later that we
>>> really need to change the layout we get serious problems.
>>>
>>> As far as I understand cmake the best cmake commandline looks like this:
>>>
>>> cmake %builddir% -G "Compiler-Makefile" -DCMAKE_INSTALL_PREFIX=%INSTALL%
>>>
>>> currently my cmake cmdline looks like this:
>>>
>>> cmake %builddir% -G "Compiler-Makefile" -DCMAKE_INSTALL_PREFIX=%INSTALL%
>>> -DCMAKE_LIBRARY_PATH=%INSTALL%/lib
>>> -DCMAKE_INCLUDE_PATH=%INSTALL%/include -DKDEWIN_DIR=%INSTALL%
>>>
>>> This is definitely not the best way: you can see that I have to repeat
>>> %INSTALL% 4 times whereas it is what both the kdewin-installer and
>>> emerge produce as the standard installation layout!
>>> My idea is to search CMAKE_INSTALL_PREFIX/include and
>>> CMAKE_INSTALL_PREFIX/lib without putting it extra to the commandline.
>>> If you have packages in different locations like %PROGRAMFILES%\gnuwin32
>>> etc. these can be searched for but should not lead to a problem. They
>>> can be included via the -DCMAKE_INCLUDE_PATH and -DCMAKE_LIBRARY_PATH
>>> then. In the end we don't need an extra KDEWIN_DIR anymore since we can
>>> use the other two variables for it.
>>>
>>> If we define a new layout later of any kind, we can thus integrate it
>>> well into that structure.
>>>
>>> disclaimer: this problem is not pressing, it just annoys me a bit and
>>> should be solved somewhen.
>> CMake cvs supports the environment variable CMAKE_FIND_PREFIX, which is a list 
>> of directories, and each of the directories will be used in the 
>> FIND_LIBRARY/PROGRAM/PATH/FILE() commands with the appropriate subdir 
>> appended (i.e. lib/, bin/ and include/).
>>
>> Does this help against that problem ?
> That sounds at least much cleaner. We would get over those search issues 
> in the end.
>> The release date for CMake 2.6.0 is not too far away (no fixed date, but it 
>> should be a few weeks). Since KDE 4.0 will not be production-ready for 
>> Windows (if I understood that correctly), would it be ok to require cmake 2.5 
>> or 2.6 under Windows ?
> I cannot decide that, that is more or less a question for all.
> There were some bugs fixed in cmake cvs which might be needed as well.
I wanted to test cmake cvs but had no time until now.


Christian