[CMake] 64 bit windows: rsp file not employed in build.make

[Verweij, Arjen]

Hi,

>The objects1.rsp file is generated by CMake during configuration.  The
>start/end temp file syntax tells NMake to use response files at build
>time.

Why is this scheme only used for shared libs and not static libs? For static libs it works automagically somehow.

>The link rule uses objects1.rsp with cl but not icl because cl.cmake
>has:
>
>  SET(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS 1)
>  SET(CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS 1)

OK. But in cl.cmake these variables are only set after the definition of CMAKE_C_CREATE_STATIC_LIBRARY and CMAKE_CXX_CREATE_STATIC_LIBRARY (i.e. for shared libs), so I didn't think of it.

>These should probably be added to Windows-icl.cmake too.  We already
>have
>
>  SET(CMAKE_Fortran_USE_RESPONSE_FILE_FOR_OBJECTS 1)
>
>in Windows-ifort.cmake.

Indeed for pure Fortran it works. I can happily link 40k files into a single lib. I have added suggested settings locally to my Windows-icl.cmake and I can build a lib from a large number of objects now.

Please find a patch attached. It has the definitions in the top like Windows-ifort.cmake (as opposed to cl.cmake)

NOTE: this does not include the change from /INCREMENTAL:YES to /INCREMENTAL:NO that stops the ICE with Intel C/C++ and Intel Fortran 9.1. I still use that locally, but after reading Bill's comments it seems the wrong way to fix it.

Thanks,
Arjen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Windows-icl.cmake.patch
Type: application/octet-stream
Size: 582 bytes
Desc: Windows-icl.cmake.patch
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100810/dc2ecac0/attachment.obj>