[CMake] Emulating --whole-archive with MSVC

[Brad King]

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