installing libs on Windows

Alexander Neundorf neundorf at
Mon Aug 6 01:46:57 BST 2007

On Sunday 05 August 2007 20:16, Andreas Pakulat wrote:
> 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
> 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.

Which ones ?
If we have such macros, I'm all for removing them. 
(I had a look at KDE4_ADD_TEST_EXECUTABLE and merging it as an extra parameter 
into KDE4_ADD_EXECUTABLE() is on my todo, reworking KDE4_INSTALL_(TS|PO|
HANDBOOK) is also on my TODO).

> 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?

Yes, objections.
1) Christian stated he sees no real need to change anything
2) users-only don't need to change the PATH if the binary Windows packages use 
the features which are currently available
3) for developers it is acceptable to adjust the PATH
4) kde4_install_libraries() would suddenly hide the install location by using 
some global variables, I don't want that, we don't have it anywhere (except 
icons), this way it becomes less obvious what's going on, if you didn't use 
the kde macros for some time, you have to learn again, as opposed if we stay 
with the plain cmake macors
5) kde4_install_libraries() would be only a partly solution.
If we really want to hide it, then lets go for a 
kde4_install((TARGETS|HEADERS|FILES) ... )
which for TARGETS uses LIB/BIN_INSTALL_DIR and sets the COMPONENT
for HEADERS it's a bit hard to say, the DESTINATION is still required, but the 
COMPONENT could be set to Devel
for FILES DESTINATION would be required and COMPONENT would be set to Default 
or something like this.


More information about the kde-core-devel mailing list