On 10/06/2016 02:06 PM, Stephen Kelly wrote: >> One could rename the variable in our own platform files >> but would have to also honor the old name just in case. > > That wouldn't be a rename.
Sure it would. All the places that set the variable would have a new more understandable name. We would just leave undocumented support for reading the old name if it is set and otherwise use the new name. Actually since this is an internal variable I'd be okay with renaming it without compatibility, so long as it is easy to add support for the old name back in if it becomes a problem in the future. Or, we could even rename support for the old name and then add a commit to remove the support. That would provide a commit that is easy to revert to restore support. >>> out of place in cmLocalGenerator. If it were returned from cli.GetItems, >> >> Yes, it could be moved. > > Ok. I might look into that. It looks like OutputLinkLibraries currently puts the flag in the linkLibs (which goes to the <LINK_LIBRARIES> placeholder) but it would more sensibly be located in the linkFlags (which goes to the <LINK_FLAGS> placeholder). If we do clean this up it should be moved to <LINK_FLAGS>. Therefore it should not go in GetItems, but instead in a separate helper that all generators can share. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
