finding top-level dirs on windows

Ralf Habacker ralf.habacker at freenet.de
Mon Mar 10 10:37:38 CET 2008


Frank Osterfeld schrieb:
> On Sunday 09 March 2008 16:13:11 Ralf Habacker wrote:
>   
>> Christian Ehrlicher schrieb:
>>     
>>> Frank Osterfeld schrieb:
>>>       
>>>> Hi,
>>>>
>>>> both Windbus and kdelibs find their installation directory by using
>>>> the path to their binary (dbus-daemon.exe and libkdecore.dll
>>>> respectively) and deduce the top-level installation directory from
>>>> there. Both work with the assumption that the binaries are located in
>>>> %INSTALLDIR%\bin.
>>>> In Gpg4win, we want to get rid of bin\ completely, as all other .exe
>>>> and .dll  files are already installed directly to %INSTALLDIR%. These
>>>> two exceptions require several workarounds so all binaries and other
>>>> resources are found correctly.
>>>>         
>> It is simple to add a check to getKde4Prefix()  to set the install
>> directory to the directory in where kdecore.dll is located, when kdecore
>> is not located in a bin dir.  The same belongs to windbus.
>>     
>
> Yes, that's what I had in mind. it's simple to patch those two functions for 
> this purpose, without changing behaviour with a layout that contains bin/. 
> Especially for dbus it makes sense to me to have that upstream. 
>
> The key can than also be used by other projects to find existing dbus installations and 
> avoid having multiple dbus versions installed.
>   
> Would you accept such a patch to windbus in case it allows KDE on Windows to 
> continue working as before? 
>   
Your are mixing two task:

1. detecting kde installation root
2. storing this root into the registry.

while i see no problem for a patch for task 1, my questions if task2 is 
really needed for your project because it has some drawbacks as already 
stated.

> (An alternative, which I dislike though: Assume 
> $INSTALLDIR/binary.exe/dll structure in case the $INSTALLDIR/bin/ check 
> failed)
>> The more important question is if this path layout change will affect
>> the whole kde4 distribution on windows because *all* binary package uses
>> the bin subdirectory for binaries and executables.
>>
>> If gpg4win will be a requirement for kde on windows applications this
>> will let into trouble.
>>     
>
> gpg4win won't depend on KDE on windows directly nor vice versa, from the KDE 
> point of view gpg4win2 is rather an alternative, heavily stripped down KDE 
> distribution (i..e. only Kleopatra, necessary parts of kdelibs, KDE icons, 
> gnupg libraries and dependencies (Qt, dbus...)).
>   
You are aware, that you are forced to maintain all required packages by 
yourself  ?  In case you haven't noticed  there are already several 
binary package available - see for example 
http://ftp.gwdg.de/pub/x11/kde/unstable/4.0.63/win32/.


There is also a buildsystem available 
http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Windows/emerge 
to which your packages could be easily added and you have the 
possibility to build your packages and all requirements as a whole and 
for debug/release mode.


Ralf






More information about the Kde-windows mailing list