installing libs on Windows

[Ralf Habacker]

Andreas Pakulat schrieb:
> On 22.07.07 20:13:37, Alexander Neundorf wrote:
>   
>> On Sunday 22 July 2007 11:33, Alex Merry wrote:
>>     
>>> On Saturday 21 Jul 2007, Alexander Neundorf wrote:
>>>       
>>>> 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})
>>>>         
>>> Is there a chance that there could be a macro that does this, so we just
>>> have something like kde4_install(kdecore kde4-config)?
>>>       
>> This should also work:
>>
>> INSTALL(TARGETS kdecore
>>                             DESTINATION ${LIB_INSTALL_DIR}
>>                             ARCHIVE DESTINATION ${STATLIB_INSTALL_DIR})
>>
>>
>> Then we can set LIB_INSTALL_DIR to bin/ on Windows, and introduce a new 
>> STATLIB_INSTALL_DIR. If somebody forgets this second part, the only problem 
>> will be that the lib file will end up in bin/ instead of lib, but I think 
>> this is not a real problem.
>>     
>
> Ok, thats fine with me (now that I understand what ARCHIVE means).
>
>   
>> So if somebody with only cmake and Linux knowledge writes library and a small 
>> kde4 app:
>>
>> add_library(mylib foo.cpp)
>> install(TARGETS mylib DESTINATION lib)
>>
>> find_package(KDE4 REQUIRED)
>> include_directories(${KDE4_INCLUDES})
>>
>> set(kfooSrcs main.cpp mywidget.cpp)
>> qt4_wrap_cpp(kfooSrcs mywidget.h)
>> add_executable(kfoo ${kfooSrcs})
>> target_link_libraries(kfoo foo ${KDE4_KDECORE_LIBS} ${KDE4_KDEUI_LIBS})
>> install(TARGETS kfoo DESTINATION bin )
>>
>> This will work, no special KDE4 macros required.
>> (it won't have automatic RPATH handling, fancy install dirs, automoc, enable 
>> final, but it will work without problems).
>>
>> IMO it would be nice if the same project without any modifications would also 
>> work under Windows, which among others means that the dlls should be found in 
>> the lib/ directory. 
>>     
>
> IMHO all this should be handled by CMake automatically. I mean I'm with
> you that it should work without further changes required on windows. But
> that would require CMake to be bit more intelligent and install dll's
> into bin/ automatically (allowing an override via the full-blown
> syntax). I don't quite understand why CMake doesn't handle this properly
> already - isn't it supposed to help with cross-platform issues?
>
>   
>> Is there a problem with adjusting the PATH when installing KDE on Windows ?
>>     
>
> Its a bit of a nuisance especially for new developers..
>
>   
>> Can something be done using the registry ?
>> Does this help us ?
>> http://www.codeguru.com/Cpp/W-P/dll/article.php/c99#more
>>     
>
> Ralf, how hard is it to change the registry inside kdewin-installer?
>   
setting the registry would be possible, but there are drawbacks. It is
then required for every installed application and it bounds installation
to the kdewin installer. Currently it is possible to unpack the zip
files by hand, set the environment and start running kde apps. This
would not be possible anymore. Additional moving the installation dir to
another place would also not possible.
> That article sounds promising and would even work if we're installing
> shortcuts into the menu or on the desktop.
>   
Shortcuts in windows start menu is planned, but there are more
environment settings required (PATH,KDEDIRS) so it looks to me that a
little exe wrapper like kwrapper which determines the required setting
at runtime would be a better solution.
I have to think more about this topic.

>> If a user downloads and installs KDE4/ a KDE4 application on Windows (e.g. 
>> kdevelop), will this have the development stuff, i.e. the .lib files and the 
>> headers ?
>>     
>
> No, lib (i.e. headers and import lib) are separated from bin in the
> packages.
>
>   
>> If not, then for developing it could be a requirement to adjust the PATH, when 
>> building a package, LIB_INSTALL_DIR can be set to bin/, so that it will just 
>> work for users. That's possible right now without any modifications.
>>     
>
> As Ralf already said, taking your example above without modifications
> except that LIB_INSTALL_DIR will be set to bin/ on win32 it would
> pollute the bin/ dir with the import and static libraries and also make
> it harder to package those development parts because the current
> packaging tool just zips up a list of files from a certain directory
> without changing their position under that directory (i.e. moving from
> one subdir to another). 
>
> So I think we should rather leave cmake-stuff as it is and see that we
> go with the registry-thing. (Unless of course thats a problem)
>
>   
For me the best solutions is if cmake would install the runtime into
bin/ by default or would have a changeable default setting for RUNTIME
DESTINATION, which could be set in KDE4Internals for all projects once.

The second best solution would be to have an install wrapper already
mentioned. There are so many kde4_... macros in kdelibs that I do not
really understand why this would be a problem.

The argument that there would be no cmake online help (--help-command)
for kde specific command could be invalidated by extending cmake's help
function with project specific command help list.

see for example kdelibs/kinit/CMakeLists.txt.

There is a kde specific _add_executable

    kde4_add_kdeinit_executable( klauncher NOGUI ${klauncher_KDEINIT_SRCS})

then the user must know that the above mentioned command produces a
hidden target kdeinit_klauncher - this is not very easy and maintable
(what if the kdeinit_ prefix has to be changed - all references has to
be patched)

    target_link_libraries(kdeinit_klauncher  ${KDE4_KIO_LIBS} )

then he has to install this hidden target by hand

    install(TARGETS kdeinit_klauncher 
        RUNTIME DESTINATION ${BIN_INSTALL_DIR}
        LIBRARY DESTINATION ${LIB_INSTALL_DIR}
        ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
    )

then he has to link the real target

    target_link_libraries( klauncher kdeinit_klauncher )

and install it 

install(TARGETS klauncher DESTINATION ${LIBEXEC_INSTALL_DIR} )

As an alternative there could be

kde4_add_kdeinit_executable( klauncher NOGUI ${klauncher_KDEINIT_SRCS})
kde4_link_kdeinit_executable( klauncher  ${KDE4_KIO_LIBS} )
kde4_install_kdeinit_executable( klauncher )

This looks easy to the project developer and maintainable because all
hidden aspects could be handled in a central place.
If cmakes help function would be able to use project specifies command
help, these command are also documented.

Similar belongs to the other target types.

Again: What is the problem ?

The third best solution is, leave it as it is.

Maybe we should chooe solution 3 and file a cmake feature request and
change this issue, when this feature is in a new cmake release.


Ralf