On 3 Aug, 2012, at 4:44 PM, Andreas Pakulat <ap...@gmx.de> wrote: > > Actually no, adding new public API, changing existing API in > compatible ways are things you can do with a shared library which > needs relinking.
Not without changing the header files, which forces recompilation. As the author of a shared library, your header files are your contract with your clients. If you change the library in such a way that requires relinking, it's your responsibility to update the contract. Everyone in the world does this and it works just fine. My point is that, unless you are deliberately trying to be really sneaky, there's pretty much no way you can introduce a change that requires relinking but not recompiling of binaries. I am not being sneaky so this is a gigantic waste of my time. > Changing the implementation is just one of the things > you can do. The point is simply, there's no way for the buildsystem to > find that out and no cmake does not provide ways to disable dependency > tracking, if you want that simply don't use a buildsystem with > dependency tracking - for example a shell script. The build system could make the reasonable assumption that a binary does not need to be relinked with a changed shared library, if that's the only thing that's changed, or this assumption could be turned on as a feature, maybe with a policy. Most other build systems have this assumption. Tracking dependencies through header files is a much smarter way to do it, and cmake already professes to do this. If cmake cannot turn off this misfeature, it needs to. -- Cheers, Leif -- 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
