Thanks for the tips Brad. I don't know if I'll have a chance to fix the
things you pointed out until Monday, but I'll eventually get around to it.
On 25/05/2011 4:21 PM, Brad King wrote:
IMO installing dependencies found on the system is outside the scope
of a build system. It already found them on the system so they are
already installed. This lies in the realm of package management.
I think trying to provide XXX_RUNTIME_LIBRARIES is much more trouble
than just the runtime directories. One never knows what transitive
runtime dependencies lie behind a library.
It's not just in the realm of package management, although that's
certainly what I use it for. (Otherwise I would have to reproduce all
of this logic in my package building script, which is certainly a waste.)
Let's assume you're using CMake to install the program into
C:\Program Files\. That's not a typical thing to do on Windows, but
it's what the INSTALL target was intended for, so let's run with it.
So you download an app that uses Qt, and you can build it and debug it
fine, because CMake sets the PATH to point include C:\Qt\4.7.0\lib (in
an ideal world where issue 8884 is implemented). Great.
But now you install the program and try to run it. Crash! No DLLs
found, because on Windows it's standard to install the DLLs into the
same directory as the .exe.
AFAIK no one is actively working on issue 8884.
This is another reason we need to know where the libraries are, because
unless issue 8884 is ever implemented, our only option is to copy the
DLLs into the build dirs.
Cheers,
-Rick-
_______________________________________________
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
