[CMake] Problem with NMake generator after upgrade from 2.4.6 to 2.6.3

[Brad King]

Dieter Oberkofler wrote:
> I have been digging into this issue and found out that the problem might be
> cause by the following command that might have changed it's behaviour in
> CMake 2.6.4
> ==========
> SET(CMAKE_CXX_LINK_EXECUTABLE "link.exe /OUT:<TARGET> > <TARGET>.ler
> ${CMAKE_START_TEMP_FILE} <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS>
> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}")
> ==========
> The linker complains about a file @CMakeFiles\LJS_049.dir\objects1.rsp that
> cannot be found.
> There is a objects1.rsp in the cmake build directories but I assume the file
> might not be searched in the proper directory.

Put <OBJECTS> before the ${CMAKE_START_TEMP_FILE}.  I don't think the linker
supports recursive response files, so it is actually looking for a file with
an '@' in it name.

> A few questions on this:
> 1) Has the behaviour changed here?

It changed from 2.4 to 2.6 but should not have from 2.6.3 to to 2.6.4.

We used to list all the object files on the command line in place of the
<OBJECTS> token.  Now we use a response file to support projects that
have a very large number of object files.

> 2) Is there now a better way to generate a file (*.ler in my example) with
> the output of the linker?

There is no official interface for this.  You can try to re-use the
rule CMake defines as much as possible:

string(REGEX REPLACE "^([^ ]+)" "\\1 > <TARGET>.ler "
   CMAKE_C_LINK_EXECUTABLE "${CMAKE_C_LINK_EXECUTABLE}")

or for MS only:

string(REGEX REPLACE "/nologo" "> <TARGET>.ler"
   CMAKE_C_LINK_EXECUTABLE "${CMAKE_C_LINK_EXECUTABLE}")

In general I would not expect full compatibility across CMake versions
for these platform rule variables.  We need to be able to change them
in the platform files to support new features or fix bugs.  We cannot
possibly test every way projects might override them.

-Brad