Brad King wrote: > The build of the project itself will not change, and even > external consumers will behave the same if they are built > with the same version of CMake.
It's confusing to me that so much of what you wrote is stuff I'm obviously already familiar with, having implemented a few policies already. I assume you're just trying to be crystal-clear, but for me it's just more confusing. I understand the intention of policies. I think the misunderstanding we're having here is that I don't know what scenario you are trying to point out which should be emitting a warning in my INTERFACE_LINK_LIBRARIES-prop branch. Or what scenario is emitting a policy warning in my branch although it shouldn't. Snippets of 'problematic' cmake code would be much more helpful than prose to understand that. > I think the case where existing code would produce different > behavior if the policy were set to NEW without other changes > is when the project sets the old LINK_INTERFACE_LIBRARIES > properties directly instead of asking tll() to do it. I think this is what we've been discussing from the beginning, is it not? That has been unit tested in my branch for a long time. It emits a warning. Maybe you missed it? Or maybe this is more 'reinforcement' and being crystal-clear? Or maybe there's a subtlety in what you wrote above that I am missing which makes it describe something different from my unit test? > * WARN (not set): Same as OLD, but tll additionally populates > a C++-only copy of what *would* have been put in the newer > INTERFACE_LINK_LIBRARIES property. Then cmTarget computes > what *would* have been the new-style link interface and > compares it to the actual link interface computed from the > OLD behavior. This comparison will indicate whether the > behavior would change and can produce the warning if so. > (We could also consider setting INTERFACE_LINK_LIBRARIES > instead of using a C++-only copy under the expectation that > the project does not know about the property anyway.) This seems to be the only different suggestion to what is already in my branch. Before implementing that though, I would like to know why the change is needed and what cmake code is 'problematic' in my branch, but would be 'fixed' by implementing the above. That way I can add a unit test for it. > With this approach there shouldn't be any policy warnings > generated for code that uses only tll(). As far as I know, this is already the case in my branch. Please post a snippet of cmake code showing the problems you are seeing so that I can easily understand them. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
