installing libs on Windows

[Andreas Pakulat]

On 24.07.07 20:27:55, Alexander Neundorf wrote:
> 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/.

Well as far as I'm concerned: the fact that install(TARGETS foo
DESTINATION <somehwere>) means install all things from that target into
<somewhere> is not really obvious. I'd wish cmake would be a bit more
intelligent here and install things as they are expected to be on the
various platforms. (which means if target is a shared lib and its on
win32 it gets a .dll and .lib and installs the first to bin/ the second
to lib/)

> ...
> > No. Thats not how windows works. Thats why they call it dll-hell ;)
> 
> No tweaking, no secret special keys ?

I don't think so, but Christian would know for sure.

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

I'll leave this up to Ralf, IIRC the packaging tool puts together the
packages automatically, i.e. it puts bin/ into the -bin package and -lib
and -include into the -lib package. So if I'm right changing
LIB_INSTALL_DIR for building a package doesn't really work.

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

Sure.

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

See above: I don't think they'll get a proper package (i.e. cluttered
with developing files).

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

Yes: qmake -project;qmake;make (and its much faster :P)

Andreas

-- 
There was a phone call for you.