Installing stuff, was: installing libs on Windows

[Alexander Neundorf]

On Monday 13 August 2007 14:22, Matthew Woehlke wrote:
> Nhuh Put wrote:
> > Hello
> > The real problem with dlls in lib/ isn't imho the need to adust the PATH
> > variable, it's rather something like sticking to the standards. Mingw,
> > cygwin, gtk, gimp, qt and every other open source program I checked puts
> > the dlls in bin/.
>
> Forget "open source", this is the standard, period. Sun (Java) does it.
> Oracle does it. *Microsoft* does it (although in typical Microsoft

Yes, correct would be if dlls go to bin.
This is about a compromise between 
easy-to-use for developers and working for users (as it is now), 
or 
a bit harder to use for developers and better working for users (the full 
syntax which does everything right)
or 
less typing for developers and a slightly more confusing build system and 
better working for users (introducing one macro which executes exactly one 
command, used for replacing one of the install() types)

Correct would be the following:

For libs and executables:
install(TARGETS foo blub 
        RUNTIME DESTINATION ${BIN_INSTALL_DIR} 
        LIBRARY DESTINATION ${LIB_INSTALL_DIR} 
        ARCHIVE DESTINATION ${BIN_INSTALL_DIR} COMPONENT Devel )

RUNTIME is the stuff which is needed for running the executable (the 
executable itself and the dll on windows). LIBRARY is the .so on UNIX, and I 
think also MODULES under windows. ARCHIVE are static libraries and the .lib 
import libraries fit in this category.
By specifying the COMPONENT Devel it will be possible for packagers to create 
devel packages for kdelibs by executing 
"cmake -DCOMPONENT=Devel cmake_install.cmake".
With some more work on cpack it may actually become possible to build kde 
packages using cpack (which can in cvs also create debian packages and which 
should be able within the next weeks to create rpm files too).

For development tools like kconfig_compiler, which are also only needed for 
development packages:

install(TARGETS kconfig_compiler 
        DESTINATION ${BIN_INSTALL_DIR} COMPONENT Devel)

Here specifying the RUNTIME, LIBRARY and ARCHIVE destinations doesn't change  
anything, since it's an executable and it has only the RUNTIME part, so the 
generic DESTINATION will be used for this, and a special DESTINATIONS for the 
LIBRARY and ARCHIVE parts aren't used anyway.


For headers (which are also only needed for development packages):
install(FILES header1.h header2.h 
        DESTINATION ${INCLUDE_INSTALL_DIR} COMPONENT Devel)

For installing everything else nothing changes:

install(FILES file1 file2 DESTINATION <whatever> )

install(PROGRAMS tool1 DESTINATION ${INCLUDE_INSTALL_DIR} )

If a macro is introduced to help with this, it must handle ALL these cases to 
be consistent. If the result would be that for some things the DESTINATION 
has to be specified but not for others it is a no-go. The same for the 
COMPONENT.

I'm for either keeping it as it is (easy for the majority of developers, 
working for the (current) majority of users) or using the full syntax 
everywhere. If this is added to the wiki this should be possible, (especially 
if this is done in most cases by copy'n paste anyway). If it is not used in 
some place it will "only" break the Windows platform, so there will be 
commits from time to time which fix just that, if not it can be fixed by 
setting the PATH by the user.

Bye
Alex