from:"Zaheer Chothia"

Re: [CMake] Windows Ninja cmcldeps.exe too verbose

2012-08-26 Thread Zaheer Chothia

I took a look at 'CMakeClDeps.cmake', where this string is detected, and
ran the
example with both compilers:

$ cl /nologo /showIncludes
C:/temp/cmcldeps_ShowIncludes/build/CMakeFiles/ShowIncludes/main.c
main.c
Note: including file:
c:\temp\cmcldeps_showincludes\build\cmakefiles\showincludes\foo.h

$ icl /nologo /showIncludes
C:/temp/cmcldeps_ShowIncludes/build/CMakeFiles/ShowIncludes/main.c
main.c
Note: including file:
C:/temp/cmcldeps_ShowIncludes/build/CMakeFiles/ShowIncludes/foo.h

Note how the Intel compiler does not normalize and lower-case the include
path.
Consequently the path replacement fails and so
CMakeFiles\CMakeCCompiler.cmake
looks like this:

set(CMAKE_CL_SHOWINCLUDE_PREFIX Note: including file:
C:/temp/cmcldeps_ShowIncludes/build/CMakeFiles/ShowIncludes/foo.h)

*--Zaheer*

On Sun, Aug 26, 2012 at 7:45 PM, Peter Kümmel syntheti...@gmx.net wrote:

 On 23.08.2012 08:53, Nils Gladitz wrote:

 I was using the Intel provided build environment (sets up environment
 variables and runs cmd.exe) with CC and CXX set to icl which apparently
 is the cause of the extra verbosity.

 When I use the same environment without CC and CXX set (which in this
 case defaults them to cl provided by visual studio 2005) ninja/cmcldeps
 keeps quiet.


 Note: including file: is generated by the compiler because of
 /ShowIncludes.

 When cl is used we detect this localized string and suppress the output.
 But it looks like this detection doesn't work for icl.

 Could you have a look at rule CXX_COMPILER in rules.build and try to
 figure out why it doesn't work for icl?

 It should look like this:

 rule CXX_COMPILER
   depfile = $DEP_FILE
   command = C:/Program Files (x86)/CMake 2.8/bin/cmcldeps.exe CXX $in
 $DEP_FILE $out Note: including file:


 Peter


  Nils

 On 08/23/2012 07:47 AM, Bill Hoffman wrote:

 On 8/22/2012 5:34 AM, Nils Gladitz wrote:

 I'm trying the Ninja generator on windows with CMake 2.8.9.

 When starting a build with ninja my console is flooded with messages
 of the form:
 Note: including file: [...] which I am guessing are generated by
 cmcldeps(?).

 It feels like all that output is slowing down the build considerably
 since the windows console is relatively slow.
 Of course it also makes actually relevant output difficult to spot.

 Is there some way to turn the messages off?

  Strange, I have not seen this at all.  What shell are you using?

 -Bill

 --

 Powered by www.kitware.com

 Visit other Kitware open-source projects at
 http://www.kitware.com/**opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake



  --

 Powered by www.kitware.com

 Visit other Kitware open-source projects at http://www.kitware.com/**
 opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] LINK_LIBRARIES not spilled to response file

2012-07-09 Thread Zaheer Chothia

Done: http://public.kitware.com/Bug/view.php?id=13385

--Zaheer

On Mon, Jul 9, 2012 at 8:15 AM, Brett Delle Grazie
brett.dellegra...@gmail.com wrote:

 On Jul 8, 2012 10:59 PM, Zaheer Chothia zaheer.chot...@gmail.com wrote:

 Hello,

 I posted a mail here [1] but have yet to receive any replies.  I think my
 last
 message was too long and detailed so let me summarize:
 * Command line length is limited on Windows.
 * To alleviate this, CMake places object files into a response file, but
 the
   same is not done for libraries.
 * This can pose a problem when the link line becomes too long.

 I am primarily interested in a solution for the Ninja generator, although
 this
 issue affects other generators too.  My previous mail contains a testcase
 and
 proposed solution.  In the interim another issue [2] was posted, but that
 is
 orthogonal and does not solve what is discussed here.

 I'd suggest you raise a defect. Kitware are pretty good at fixing things or
 suggesting temporary workarounds until the underlying issue is fixed.


 Kind regards,

 --Zaheer

 [1]: http://www.cmake.org/pipermail/cmake/2012-June/051065.html
 [2]: http://public.kitware.com/Bug/view.php?id=13366

 On Thu, Jun 28, 2012 at 3:50 PM, Zaheer Chothia zaheer.chot...@gmail.com
 wrote:

 Hello,

 I encountered an issue while building a CMake project where one target is
 linked
 against a large number of libraries.  Unlike object files, libraries are
 not
 placed into a response file, which can lead to build commands which
 exceed the
 length limits on Windows.  For reference, I am using the CMake 2.8.9-rc1
 and
 Ninja generator with Microsoft compilers.

 Following this mail is a testcase generator [1] to demonstrate this issue
 (sample project attached for convenience).  The build fails with this
 error (for
 readibility I replaced a long sequence of libraries with ...):

 FAILED: cmd.exe /c cd.  C:\Program Files
 (x86)\CMake\bin\cmake.exe -E vs_link_exe
 C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe  /nologo @hello.exe.rsp  /DWIN32
 /D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi  /Ob0 /Od /RTC1 /Fehello.exe
 /Fdhello.pdb -link /implib:hello.lib /version:0.0  /STACK:1000
 /machine:X86  /debug /INCREMENTAL /subsystem:console
 src\abcdefghijklmnopqrstuvwxyz0123456789\library1.lib
 src\abcdefghijklmnopqrstuvwxyz0123456789\library2.lib ...
 kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
 oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  cd.
 The command line is too long.

 ninja: build stopped: subcommand failed.

 Although this example may seem artificial, with the use case I refer to
 (i)
 libraries are are specified by absolute paths so they are indeed
 reasonably long
 and (ii) since there are third-party libraries involved I would not be
 able to
 simply combine source files into one large library as is possible here.
 I
 should also mention that this issue does not affect the Visual Studio
 generators, however it is present with the following: Ninja, MinGW
 Makefiles, NMake Makefiles, MSYS Makefiles.  For Ninja I suspect that the
 indirection via cmd.exe imposes a maximum command length of 8192 KB,
 whereas for
 the others this will likely be 32 KB (CreateProcess).

 I would be quite content if this is fixed for the Ninja generator.  A
 simple fix
 would be to adapt the build rules by moving $LINK_LIBRARIES from
 'command' to
 'rspfile_content':

 --- rules.ninja.bak 2012-06-28 15:23:35 +0100
 +++ rules.ninja 2012-06-28 15:38:09 +0100
 @@ -40,10 +40,10 @@
  # Rule for linking C executable.

  rule C_EXECUTABLE_LINKER_RSPFILE
 -  command = cmd.exe /c $PRE_LINK  C:\Program Files
 (x86)\CMake\bin\cmake.exe -E vs_link_exe
 C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe  /nologo @$out.rsp  $FLAGS
 /Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
 $LINK_FLAGS $LINK_LIBRARIES  $POST_BUILD
 +  command = cmd.exe /c $PRE_LINK  C:\Program Files
 (x86)\CMake\bin\cmake.exe -E vs_link_exe
 C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe  /nologo @$out.rsp  $FLAGS
 /Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
 $LINK_FLAGS  $POST_BUILD
description = Linking C executable $out
rspfile = $out.rsp
 -  rspfile_content = $in
 +  rspfile_content = $in $LINK_LIBRARIES

 Best,

 --Zaheer

  [1]: BEGIN: testcase.sh
 ---
 #!/bin/bash -e

 NUM_LIBRARIES=500
 # Use a long path to quickly exhaust the command-line length limit.
 SRC_DIR=src/abcdefghijklmnopqrstuvwxyz0123456789

 # Root directory: application and CMakeLists.txt
 echo int main() { return 0; }  hello.c

 cat  EOF  CMakeLists.txt
 cmake_minimum_required(VERSION 2.8)

 project(Hello)

 add_subdirectory($SRC_DIR)

 add_executable(hello hello.c)
 target_link_libraries(hello
 EOF

 for ((i = 1; i = $NUM_LIBRARIES; i++)); do
 echo library$i  CMakeLists.txt
 done

 echo )  CMakeLists.txt

 # Libraries: sources and CMakeLists.txt
 mkdir -p $SRC_DIR
 [[ -f

Re: [CMake] LINK_LIBRARIES not spilled to response file

2012-07-08 Thread Zaheer Chothia

Hello,

I posted a mail here [1] but have yet to receive any replies.  I think my
last
message was too long and detailed so let me summarize:
* Command line length is limited on Windows.
* To alleviate this, CMake places object files into a response file, but the
  same is not done for libraries.
* This can pose a problem when the link line becomes too long.

I am primarily interested in a solution for the Ninja generator, although
this
issue affects other generators too.  My previous mail contains a testcase
and
proposed solution.  In the interim another issue [2] was posted, but that is
orthogonal and does not solve what is discussed here.

Kind regards,

*--Zaheer*
*
*
[1]: http://www.cmake.org/pipermail/cmake/2012-June/051065.html
[2]: http://public.kitware.com/Bug/view.php?id=13366

On Thu, Jun 28, 2012 at 3:50 PM, Zaheer Chothia zaheer.chot...@gmail.comwrote:

 Hello,

 I encountered an issue while building a CMake project where one target is
 linked
 against a large number of libraries.  Unlike object files, libraries are
 not
 placed into a response file, which can lead to build commands which exceed
 the
 length limits on Windows.  For reference, I am using the CMake 2.8.9-rc1
 and
 Ninja generator with Microsoft compilers.

 Following this mail is a testcase generator [1] to demonstrate this issue
 (sample project attached for convenience).  The build fails with this
 error (for
 readibility I replaced a long sequence of libraries with ...):

 FAILED: cmd.exe /c cd.  C:\Program Files
 (x86)\CMake\bin\cmake.exe -E vs_link_exe
 C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe  /nologo @hello.exe.rsp  /DWIN32
 /D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi  /Ob0 /Od /RTC1 /Fehello.exe
 /Fdhello.pdb -link /implib:hello.lib /version:0.0  /STACK:1000
 /machine:X86  /debug /INCREMENTAL /subsystem:console
 src\abcdefghijklmnopqrstuvwxyz0123456789\library1.lib
 src\abcdefghijklmnopqrstuvwxyz0123456789\library2.lib ...
 kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
 oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  cd.
 The command line is too long.

 ninja: build stopped: subcommand failed.

 Although this example may seem artificial, with the use case I refer to (i)
 libraries are are specified by absolute paths so they are indeed
 reasonably long
 and (ii) since there are third-party libraries involved I would not be
 able to
 simply combine source files into one large library as is possible here.  I
 should also mention that this issue does not affect the Visual Studio
 generators, however it is present with the following: Ninja, MinGW
 Makefiles, NMake Makefiles, MSYS Makefiles.  For Ninja I suspect that the
 indirection via cmd.exe imposes a maximum command length of 8192 KB,
 whereas for
 the others this will likely be 32 KB (CreateProcess).

 I would be quite content if this is fixed for the Ninja generator.  A
 simple fix
 would be to adapt the build rules by moving $LINK_LIBRARIES from 'command'
 to
 'rspfile_content':

 --- rules.ninja.bak 2012-06-28 15:23:35 +0100
 +++ rules.ninja 2012-06-28 15:38:09 +0100
 @@ -40,10 +40,10 @@
  # Rule for linking C executable.

  rule C_EXECUTABLE_LINKER_RSPFILE
 -  command = cmd.exe /c $PRE_LINK  C:\Program Files
 (x86)\CMake\bin\cmake.exe -E vs_link_exe
 C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe  /nologo @$out.rsp  $FLAGS
 /Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
 $LINK_FLAGS $LINK_LIBRARIES  $POST_BUILD
 +  command = cmd.exe /c $PRE_LINK  C:\Program Files
 (x86)\CMake\bin\cmake.exe -E vs_link_exe
 C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe  /nologo @$out.rsp  $FLAGS
 /Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
 $LINK_FLAGS  $POST_BUILD
description = Linking C executable $out
rspfile = $out.rsp
 -  rspfile_content = $in
 +  rspfile_content = $in $LINK_LIBRARIES

 Best,

 --Zaheer

  [1]: BEGIN: testcase.sh
 ---
 #!/bin/bash -e

 NUM_LIBRARIES=500
 # Use a long path to quickly exhaust the command-line length limit.
 SRC_DIR=src/abcdefghijklmnopqrstuvwxyz0123456789

 # Root directory: application and CMakeLists.txt
 echo int main() { return 0; }  hello.c

 cat  EOF  CMakeLists.txt
 cmake_minimum_required(VERSION 2.8)

 project(Hello)

 add_subdirectory($SRC_DIR)

 add_executable(hello hello.c)
 target_link_libraries(hello
 EOF

 for ((i = 1; i = $NUM_LIBRARIES; i++)); do
 echo library$i  CMakeLists.txt
 done

 echo )  CMakeLists.txt

 # Libraries: sources and CMakeLists.txt
 mkdir -p $SRC_DIR
 [[ -f $SRC_DIR/CMakeLists.txt ]]  rm $SRC_DIR/CMakeLists.txt
 for ((i = 1; i = $NUM_LIBRARIES; i++)); do
 echo int function$i() { return $i; }  $SRC_DIR/function$i.c
 echo add_library(library$i function$i.c)  $SRC_DIR/CMakeLists.txt
 done

 echo Testcase has been setup: now build with CMake and Ninja generator.
  [1]: END: testcase.sh

[CMake] LINK_LIBRARIES not spilled to response file

2012-06-28 Thread Zaheer Chothia

Hello,

I encountered an issue while building a CMake project where one target is linked
against a large number of libraries.  Unlike object files, libraries are not
placed into a response file, which can lead to build commands which exceed the
length limits on Windows.  For reference, I am using the CMake 2.8.9-rc1 and
Ninja generator with Microsoft compilers.

Following this mail is a testcase generator [1] to demonstrate this issue
(sample project attached for convenience).  The build fails with this error (for
readibility I replaced a long sequence of libraries with ...):

FAILED: cmd.exe /c cd.  C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe  /nologo @hello.exe.rsp  /DWIN32
/D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi  /Ob0 /Od /RTC1 /Fehello.exe
/Fdhello.pdb -link /implib:hello.lib /version:0.0  /STACK:1000
/machine:X86  /debug /INCREMENTAL /subsystem:console
src\abcdefghijklmnopqrstuvwxyz0123456789\library1.lib
src\abcdefghijklmnopqrstuvwxyz0123456789\library2.lib ...
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  cd.
The command line is too long.

ninja: build stopped: subcommand failed.

Although this example may seem artificial, with the use case I refer to (i)
libraries are are specified by absolute paths so they are indeed reasonably long
and (ii) since there are third-party libraries involved I would not be able to
simply combine source files into one large library as is possible here.  I
should also mention that this issue does not affect the Visual Studio
generators, however it is present with the following: Ninja, MinGW
Makefiles, NMake Makefiles, MSYS Makefiles.  For Ninja I suspect that the
indirection via cmd.exe imposes a maximum command length of 8192 KB, whereas for
the others this will likely be 32 KB (CreateProcess).

I would be quite content if this is fixed for the Ninja generator.  A simple fix
would be to adapt the build rules by moving $LINK_LIBRARIES from 'command' to
'rspfile_content':

--- rules.ninja.bak 2012-06-28 15:23:35 +0100
+++ rules.ninja 2012-06-28 15:38:09 +0100
@@ -40,10 +40,10 @@
 # Rule for linking C executable.

 rule C_EXECUTABLE_LINKER_RSPFILE
-  command = cmd.exe /c $PRE_LINK  C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe  /nologo @$out.rsp  $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $LINK_LIBRARIES  $POST_BUILD
+  command = cmd.exe /c $PRE_LINK  C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe  /nologo @$out.rsp  $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS  $POST_BUILD
   description = Linking C executable $out
   rspfile = $out.rsp
-  rspfile_content = $in
+  rspfile_content = $in $LINK_LIBRARIES

Best,

--Zaheer

 [1]: BEGIN: testcase.sh ---
#!/bin/bash -e

NUM_LIBRARIES=500
# Use a long path to quickly exhaust the command-line length limit.
SRC_DIR=src/abcdefghijklmnopqrstuvwxyz0123456789

# Root directory: application and CMakeLists.txt
echo int main() { return 0; }  hello.c

cat  EOF  CMakeLists.txt
cmake_minimum_required(VERSION 2.8)

project(Hello)

add_subdirectory($SRC_DIR)

add_executable(hello hello.c)
target_link_libraries(hello
EOF

for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo library$i  CMakeLists.txt
done

echo )  CMakeLists.txt

# Libraries: sources and CMakeLists.txt
mkdir -p $SRC_DIR
[[ -f $SRC_DIR/CMakeLists.txt ]]  rm $SRC_DIR/CMakeLists.txt
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo int function$i() { return $i; }  $SRC_DIR/function$i.c
echo add_library(library$i function$i.c)  $SRC_DIR/CMakeLists.txt
done

echo Testcase has been setup: now build with CMake and Ninja generator.
 [1]: END: testcase.sh ---


cmake_testcase_many_libraries_rspfile.tar.bz2
Description: BZip2 compressed data
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Support for Intel Visual Fortran 2013 Beta

2012-06-01 Thread Zaheer Chothia

Hello,

Visual Studio fails to load the project files (.vfproj) generated by CMake 2.8.8
when using the Intel Visual Fortran 2013 Beta [1]:

The selected project was created by a later version of Intel(R)
Visual Fortran.
 It cannot be loaded with this version.

Projects generated by the wizard within Visual Studio have the version set to
11.0, as was the case with Intel Fortran 11.x and 12.x.  This issue is easy to
diagnose (see patch following this mail) and I have tested that it works with:

Microsoft Visual Studio 10.0.40219.1
Intel Visual Fortran 13.0.0.041 Beta Build 20120425

(I am posting this mostly for others who may be searching for the
error message above.)

--Zaheer

[1]: http://software.intel.com/en-us/forums/showthread.php?t=104792

--- a/Source/cmLocalVisualStudio7Generator.cxx
+++ b/Source/cmLocalVisualStudio7Generator.cxx
@@ -1933,9 +1933,10 @@ cmLocalVisualStudio7Generator
   vskey += \\Packages\\ CM_INTEL_PLUGIN_GUID ;ProductVersion;
   cmSystemTools::ReadRegistryValue(vskey.c_str(), intelVersion,
cmSystemTools::KeyWOW64_32);
-  if (intelVersion.find(12) == 0 || (intelVersion.find(11) == 0))
+  if (intelVersion.find(13) == 0 || intelVersion.find(12) == 0 ||
+  intelVersion.find(11) == 0)
 {
-// Version 11.x and 12.x actually use 11.0 in project files!
+// Version 11.x, 12.x and 13.x actually use 11.0 in project files!
 intelVersion = 11.0 ;
 }
   else if(intelVersion.find(10) == 0)
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Windows Ninja cmcldeps.exe too verbose

Re: [CMake] LINK_LIBRARIES not spilled to response file

Re: [CMake] LINK_LIBRARIES not spilled to response file

[CMake] LINK_LIBRARIES not spilled to response file

[CMake] Support for Intel Visual Fortran 2013 Beta

5 matches

Site Navigation

Mail list logo

Footer information