installing libs on Windows

[Andreas Pakulat]

On 24.07.07 18:46:50, Alexander Neundorf wrote:
> 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.

What I meant to say is: Inspect the target that should be installed and
see wether it builds a shared lib or not. If it builds a shared lib and
we're on win32 don't install it into LIBRARY but into RUNTIME -
automatically.

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

No. Thats not how windows works. Thats why they call it dll-hell ;)

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

IIRC it was mentioned on the cmake list that this is still experimental
stuff (the 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.

What I said was that changing LIB_INSTALL_DIR to bin/ in a central place
will make it harder to provide packages from the installed files and
also would need extra magic later on because bin/ needs to be added to
the library-search-paths (so the linker finds the import libs)

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

No, currently the requirement is that _everybody_ adds bin and lib to
PATH. And as Ralf said there some ways to fix that.

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

I do understand your points, but obviously KDE developers are pretty
reluctant to change all CMakeLists.txt (with shared libs) to the more
verbose syntax. Which (as far as I can tell) leaves only the option to
change PATH somehow. But this will break when users install libs and
apps to different dirs (or at least will get hard to do), when they just
unpack the package into some arbitrary directory or when they move
around the libs. 

Andreas

PS: While cmake is pretty easy to setup, I still use qmake for simple
test apps ;) Its even easier...

-- 
You will be held hostage by a radical group.