On 09/11/2015 02:09 PM, Brad King wrote: > I would be very happy to get rid of the vs_link_exe and vs_link_dll code. > The source is full of comments about why it is there (incremental linking). > If someone can get an alternative approach working that also supports > user-provided .manifest files I would be happy to review it.
There is documentation here about what those are doing: https://msdn.microsoft.com/en-us/library/ms235591.aspx http://blogs.msdn.com/b/zakramer/archive/2006/05/22/603558.aspx IIRC vs_link_{exe,dll} is needed to implement these steps due to all the conditions that decide which parts are needed. MSBuild must have something similar in its own build rules to achieve incremental linking with embedded manifests. Perhaps vs_link_{exe,dll} can be updated to handle user-provided manifest files. > Actually I think this should be done before the Windows 10 support can > be integrated. We need to make sure that when a .manifest file is added > to the list of sources for an exe or dll target that we can properly > honor it in all generators. Otherwise adding support for non-VS generators > later will be a behavior change. Also we need to make sure the semantics > of specifying manifest sources works everywhere. This needs to be resolved for proper Windows 10 support to be integrated since that needs user-provided manifest files to work. -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
