installing libs on Windows

[Alexander Neundorf]

On Tuesday 24 July 2007 05:29, Ralf Habacker wrote:
> Andreas Pakulat schrieb:
> > On 22.07.07 20:13:37, Alexander Neundorf wrote:
...
> >> 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

CMake can't guess where to install stuff.
Or do you mean something like:
set(CMAKE_RUNTIME_INSTALL_DIR bin)
...
install(TARGETS kdecore DESTINATION lib) 
install(TARGETS kde4-config)
  -> no destination given, use the global setting ?

Or maybe:
install(TARGETS kdecore DESTINATION lib) 

no destinations for RUNTIME, LIBRARY, ARCHIVE explicitely given, use the 
global settings if they exist (hmm, this won't be accepted, if the command 
says "lib", it should end up in "lib").

No matter whether this feature might actually go into cmake, even if it would, 
it would be not before cmake 2.6.0 (probably released still this year or 
early next year), which would then be required for KDE4. We can't do this 
(while it might be a nice idea).

Maybe default components for the three target parts (RUNTIME, ARCHIVE, 
LIBRARY) would also be a good idea (see below).

> > syntax). I don't quite understand why CMake doesn't handle this properly
> > already - isn't it supposed to help with cross-platform issues?

It does, with the syntax below you can do everything you want for all 
platforms at once.

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

Is it also possible to do this registry thingy not for every single 
application, but somehow more general, like all apps which match a pattern, 
or which are in a specified directory, or which link to some library 
(kdecore) ?

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

Can you explain a bit more ?
E.g. in VTK there are additional to the "normal" executables helper 
executables created, which search the executables and the dlls, set up the 
PATH and then execute the actual executable.

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

How does this separation happen currently ?
I think (I just saw it somewhere, didn't try it) this is actually also 
supported by INSTALL().
You can do e.g.
install(TARGETS kdecore kde4-config 
           RUNTIME DESTINATION bin COMPONENT Runtime
           LIBRARY DESTINATION lib COMPONENT Runtime
           ARCHIVE DESTINATION lib COMPONENT Devel)

install(FILES foo.h bar.h DESTINATION include COMPONENT Devel)
install(FILES blub.xml DESTINATION share/data COMPONENT Runtime)

and then (I guess via executing cmake_install.cmake directly with some 
parameter) you can install selected "components", so that for a user package 
you wouldn't install the "Devel" component, for a developer install you would 
install all components, for a "devel" package only the "Devel" component.

> >> 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).

Not sure I understand.
So if you would develop with LIB_INSTALL_DIR=lib (with setting PATH), and when 
building a release, set LIB_INSTALL_DIR to bin (no PATH required then).
So developers would have to adjust the PATH, normal users who install their 
binary packages don't have to. 

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

That's planned, patches are welcome :-)
But still this wouldn't make these docs appear on the man page.

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

I don't claim everything is perfect, but I think most stuff is quite  clear in 
what it does.

...
> This looks easy to the project developer and maintainable because all
> hidden aspects could be handled in a central place.

I'd like to have as few "hidden aspects" as possible. Putting stuff into 
macros hides aspects. If it really helps, we'll do it. If it's not really 
required, I'm against it. Currently I have the impression that all what is 
required is that developers set the PATH, users who install from a binary 
package don't have to. 

Also I'd like if KDE developers can use their cmake knowledge they have from 
KDE also for non-KDE projects, where they don't have all the convenience 
macros. It's really easy to build simple software with cmake, but if a KDE 
developer gets the feeling he can't do anything because he doesn't have the 
KDE macros then it's a problem IMO. That's why the 
KDE4_ADD_EXECUTABLE/LIBRARY/PLUGIN() take as much as possible the same 
arguments (and have the same name) as the original cmake commands and that's 
why I don't want to hide also the INSTALL() command which can do everything 
we want (albeit to only almost our complete satisfaction).
...and having more macros means more processing time by cmake.

Bye
Alex