installing libs on Windows

[Andreas Pakulat]

On 20.07.07 22:55:15, Alexander Neundorf wrote:
> Hi,
> 
> on Windows there is no RPATH, so the only way for executables to find their 
> dlls (e.g. kdecore.dll) is that either 
> A) the dlls are in the same directory as the executable, or 
> B) the directory where the dlls are is in the PATH.
> 
> In KDE4 we currently do:
> INSTALL(TARGETS kdecore DESTINATION ${LIB_INSTALL_DIR})
> This means we rely on option B).
> 
> We could do the following:
> INSTALL(TARGETS kdecore 
>                              LIBRARY DESTINATION ${LIB_INSTALL_DIR}
>                              RUNTIME DESTINATION ${BIN_INSTALL_DIR}
>                              ARCHIVE DESTINATION ${LIB_INSTALL_DIR})
> 
> This will install the .so and .dylib files to LIB_INSTALL_DIR ("LIBRARY"), 
> the .dll files and executables to BIN_INSTALL_DIR ("RUNTIME") and the .lib 
> and .a files also to LIB_INSTALL_DIR ("ARCHIVE").
> 
> It is then also possible to install libs and executables with one command:
> INSTALL(TARGETS kdecore  kde4-config
>                              LIBRARY DESTINATION ${LIB_INSTALL_DIR}
>                              RUNTIME DESTINATION ${BIN_INSTALL_DIR}
>                              ARCHIVE DESTINATION ${LIB_INSTALL_DIR})
> 
> The Windows developers would prefer this, the executables will be able to run 
> without changing the PATH. How will the executables actually be installed ? 
> Via an installer which can also adjust the PATH maybe ?
> 
> Anyway, this would mean that this full syntax has to be used for every 
> installed library, otherwise it won't work on Windows.
> As it is now, it's a bit harder for the Windows guys but safes the average 
> Linux KDE hacker from thinking about Windows and he can just do 
> INSTALL(TARGETS mylib DESTINATION lib)
> (of course LIB_INSTALL_DIR is better but in most cases it's just the same 
> result) and it will still work on Windows (if the system is already able to 
> run any KDE app).
> 
> So, are their objections against using the full INSTALL() syntax everywhere ?

This is more or less a ping, as discussion somehow stopped without
result and we (win32 devs) like to get a result.

So far its pretty obvious that nobody wants to use the full install
syntax all over kde as thats too much work to convert now (its also a
bit harder to write a script for this I think).

So IMHO the new-macro-option is the best choice. The idea Alex had with
changing LIB_INSTALL_DIR, PLUGIN_INSTALL_DIR and LIBEXEC_INSTALL_DIR
is as tedious as changing to the full syntax. Currently packages are
normally built from the normal development builds, we (win32 devs) don't
have the time and resources to do separate builds just for packaging and
we already provide packages so that new developers don't have to start
from scratch (and don't run into the daily build-issues we still face)

I still don't see the problem with a kde4_add_library() macro, there are
tons of macro's already for various things that can be done with one or
two lines of cmake code.

I'm including the macro proposed by PutHuhn here again and asking if
there are objections against adding this macro and converting
trunk/KDE+koffice to use this macro for its installed shared libraries?

Andreas

-- 
Just because the message may never be received does not mean it is
not worth sending.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: windows_bin2.patch
Type: text/x-diff
Size: 1268 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070806/64c75730/attachment.patch>