installing libs on Windows

[Alexander Neundorf]

On Tuesday 24 July 2007 19:33, Andreas Pakulat wrote:
> On 24.07.07 18:46:50, Alexander Neundorf wrote:
...
> > 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.

It does that, it installs it where you tell it to. If you tell it "everything 
to lib/" everything goes to lib/. If you tell it "RUNTIME to bin/, ARCHIVE to 
lib/", it will do this, exe and dll to bin/, lib to lib/.

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

No tweaking, no secret special keys ?

...
> IIRC it was mentioned on the cmake list that this is still experimental
> stuff (the component).

I'll check tomorrow.

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

Long form: "with the current cmake files and the current way the binary 
packages are created it is required that everybody sets PATH".

But isn't the following possible right now ?
As a developer, you set only CMAKE_INSTALL_PREFIX and the dlls and libs will 
go into lib/, so you have to set PATH.
When building for a release package, set LIB_INSTALL_DIR to bin/ (using "make 
edit_cache" or CMakeSetup or ccmake or edit CMakeCache.txt)  and build with 
this LIB_INSTALL_DIR, so the dlls will go to bin/ and the .lib and .a file 
will not be packaged anyway if I understood correctly.

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

Which users are we talking about ?
Developers who are able to setup their windows machine in such a way that they 
can build KDE software ? I think this group of people is able to set the 
PATH.
The users, who just download a binary package can get a package where setting 
PATH is not required, right now, with no changes to the cmake files, if the  
XXX_INSTALL_DIR variables are set appropriately.

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

Easier than add_executable(foo main.cpp) ? ;-P

Alex