On Monday 21 September 2009 03:27:43 pm Tyler Roscoe wrote: > On Mon, Sep 21, 2009 at 12:37:06PM -0600, Clinton Stimpson wrote: > > I don't know about your setup, but for our apps, our developers just set > > the PATH environment variable for their dlls not built as part of the > > project. > > This works well for developers but often works less well for testers, or > for making sure that our built packages have all the runtimes they need > and can run on a virgin machine.
Our nightly build/test machines create packages and posts them for our testers or adventurous users. Packaging it is also a test. If a 3rd party dll doesn't get bundled up and its needed, the test fails (BundleUtilities.cmake has a verification step that helps us catch incomplete packages). > > It's also nice if the local CMake system can take care of the > dependencies because then upgrading a thirdparty library is just setting > a new path or new version number in the CMake system and it works for > everyone. If we rely on PATH instead, then each developer has to do work > every time we change a 3rdparty dependency. Well, that depends on your dependencies and how they are included. We try to put most of them in the source tree so each developer makes their own. Having to deploy multiple binaries for multiple compilers on multiple platforms just for developers isn't fun. So we're down to just a few binary packages that we have to distribute to developers. They don't change often enough for maintainence of the PATH env. variable to be a problem. Clint _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
