Is there anything that would convince kitware that the behavior I describe is worth pursuing, even as a non-default option? I'd implement it myself but your code is foreign to me and I bet someone at kitware knows the exact line that needs to change to enable this.
The reason I'm pushing so hard on this is that my project builds several libraries and each is tested individually, and furthermore, each library builds a shared and a static library and there are a few tests that test the static library but most test the shared library. Obviously the statically linked tests cannot use the optimization I described. So if I'm developing, I can't just build one library target always, I may need to build different library targets depending on what code I'm modifying, and in most cases I need to build multiple library targets and a few statically linked tests. Having to do this manually is a big pain, and the natural place to do it is right in the build system, since it already has all the information needed for these decisions. For me, this is a big regression from Make and Autotools. Not big enough to switch back, certainly, but very big. Sent from my iPhone On Oct 25, 2012, at 16:26, Bill Hoffman <bill.hoff...@kitware.com> wrote: > On 10/25/2012 1:17 PM, Leif Walsh wrote: >> Yes, but this is a very rare thing to do. And the "failure" result is >> just that the problem would be discovered at test time instead of link >> time. >> >> What's being proposed here is a massive optimization for the common case >> (changing code in a library and not changing the API or tests) by >> sacrificing a little bit of latency (the time between link and test) in >> the extremely rare case. >> >> I wouldn't think this would be a hard tradeoff to make. Could it be added >> at least as an option? > CMake errs on the side of being correct. If you do not want to relink, you > can just build the library target directly with the /fast option or without > it. > > Let's say you have a project with shared library foo and executable bar. You > have four options: > > make foo // build library foo and anything foo depends on > > make foo/fast // build just foo and nothing it depends on > > make bar // build bar and anything it depends, with a possible relink when > foo changes > > make // build all targets in the project, will relink bar when foo changes > > > -- > Bill Hoffman > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > bill.hoff...@kitware.com > http://www.kitware.com > 518 881-4905 (Direct) > 518 371-3971 x105 > Fax (518) 371-4573 > -- > > 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 -- 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
