On 05/02/2016 11:03 AM, Guillaume Dumont wrote: > emulate the --whole-archive link flag with MSVC
FYI, this is the purpose of OBJECT libraries in CMake. However, currently OBJECT libraries cannot be installed or used externally. This limitation is primarily due to difficulty in defining semantics, particularly in the case of transitive linking. > 1. WINDOWS_LINK_WHOLE_ARCHIVE is set on the library > 2. CMake catches this and list all the object files into a file and > calls itself via cmake -E __create_whole_archive_rsp_file which creates > a response file containing a list of /INCLUDE:"<symbolname>" > 3. CMake adds this response file to the INTERFACE_LINK_LIBRARIES of > the target so that consuming projects automatically link in all the > symbols defined in the library. > 4. Then cmake would have the handle the installation of this response file, > etc. Currently adding --whole-archive to INTERFACE_LINK_LIBRARIES is not well defined. It is only safe to add such flags in the target_link_libraries call of the final binary. This would be done on the client side. Therefore all of the above steps to simulate it should be done on the client side too and there is no need to do anything ahead of time or install anything. The way we express this on the client side with OBJECT libraries is to specify $<TARGET_OBJECTS:objlib> as sources of the consuming target in its add_library or add_executable call. This eliminates any sense of "linking" to the library in CMake's model of the project and therefore avoids having to define semantics for usage requirements and transitive linking of object libraries. > Is it currently possible to add a response file to the link line via > target_link_libraries or via target properties? Yes, but it is safe only to do this on the final binary and cannot currently be expressed as usage requirements on the library itself. For upstream support of the relevant use cases I'd prefer to see if OBJECT libraries can be made to handle them. This will be more portable than the platform-specific solution proposed here. Discussion of this work would be better held on the dev list: https://cmake.org/mailman/listinfo/cmake-developers -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
