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
