Brad King wrote: > The variable name refers to flags needed when linking an executable *to* > shared libraries. It is a terrible name that has been around since the > earliest days. 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. The infinite compatibility promises of CMake concern me. A policy could be added but those are also defined to never expire, so while they help users migrate, they don't help clean up code. End result: do nothing. >> Also, shouldn't that code be part of cmComputeLinkInformation? It seems >> out of place in cmLocalGenerator. If it were returned from cli.GetItems, >> then cmLocalVisualStudio7GeneratorInternals::OutputLibraries and >> cmGlobalXCodeGenerator::AddDependAndLinkInformation would make use of it, >> which as far as I can tell they currently do not. Should/do those >> generators support ENABLE_EXPORTS? > > Yes, it could be moved. It hasn't really mattered because the variable > is not populated on the platforms supported by those other generators. Ok. I might look into that. Thanks, Steve. -- 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
