View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014428CMakeCMakepublic2013-09-20 14:372016-06-10 14:31
ReporterRob Stewart 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionmoved 
PlatformWindowsOSOS Version
Product VersionCMake 2.8.11 
Target VersionFixed in Version 
Summary0014428: Enabling Verbose NMAKE Builds
DescriptionThe current recommendation for verbose NMAKE builds, described at http://www.cmake.org/Wiki/CMake_FAQ#Is_there_an_option_to_produce_more_.27verbose.27_compiling.3F, [^] is unsatisfactory. While I would prefer a better option, the following variation of what appears in Windows.cmake would be much better:

...
set(CMAKE_START_TEMP_FILE "")                                        # +
set(CMAKE_END_TEMP_FILE "")                                          # +

# for borland make long command lines are redirected to a file
# with the following syntax, see Windows-bcc32.cmake for use
if(CMAKE_GENERATOR MATCHES "Borland" AND NOT CMAKE_VERBOSE_MAKEFILE) # +
  set(CMAKE_START_TEMP_FILE "@&&|\n")
  set(CMAKE_END_TEMP_FILE "\n|")
endif()

# for nmake make long command lines are redirected to a file
# with the following syntax, see Windows-bcc32.cmake for use
if(CMAKE_GENERATOR MATCHES "NMake" AND NOT CMAKE_VERBOSE_MAKEFILE)   # +
  set(CMAKE_START_TEMP_FILE "@<<\n")
  set(CMAKE_END_TEMP_FILE "\n<<")
endif()

include(Platform/WindowsPaths)


That variation uses CMAKE_VERBOSE_MAKEFILE to control whether to use batch files.

A better solution, I suspect, is to add conditional lines to the makefiles, controlled by CMAKE_VERBOSE_MAKEFILE, that cat -- sorry, type -- the batch files before running them.
TagsNo tags attached.
Attached Filespatch file icon Windows.cmake.patch [^] (1,667 bytes) 2013-09-20 15:16 [Show Content]

 Relationships

  Notes
(0033852)
Bill Hoffman (manager)
2013-09-20 15:07

 That sounds like a good idea. Are you willing to create a patch? I am also not sure if nmake support conditionals. If you could just hand edit a cmake created nmake file to do what you suggest and post that, we could get it into CMake pretty easy.
(0033853)
Rob Stewart (reporter)
2013-09-20 15:16

 I attached a patch with my changes.

Re: Conditionals in nmake, they are supported according to http://msdn.microsoft.com/en-us/library/7y32zxwh.aspx: [^]

 !IF constantexpression

    Processes statements between !IF and the next !ELSE or !ENDIF if constantexpression evaluates to a nonzero value.
!IFDEF macroname

    Processes statements between !IFDEF and the next !ELSE or !ENDIF if macroname is defined. A null macro is considered to be defined.
!IFNDEF macroname

    Processes statements between !IFNDEF and the next !ELSE or !ENDIF if macroname is not defined.
!ELSE[IF constantexpression | IFDEF macroname| IFNDEF macroname]

    Processes statements between !ELSE and the next !ENDIF if the prior !IF, !IFDEF, or !IFNDEF statement evaluated to zero. The optional keywords give further control of preprocessing.
!ELSEIF

    Synonym for !ELSE IF.
!ELSEIFDEF

    Synonym for !ELSE IFDEF.
!ELSEIFNDEF

    Synonym for !ELSE IFNDEF.
!ENDIF

    Marks the end of an !IF, !IFDEF, or !IFNDEF block. Any text after !ENDIF on the same line is ignored.
(0033854)
Rob Stewart (reporter)
2013-09-20 15:21

 Sorry, there's an extra closing parenthesis on the following line of the patch:

+if(CMAKE_GENERATOR MATCHES "Borland" AND NOT CMAKE_VERBOSE_MAKEFILE))
(0033855)
Bill Hoffman (manager)
2013-09-20 16:23

 The patch just gets rid of the command line redirects. I don't think we want that patch, as the build might be broken by turning on VERBOSE. The reason we have to use the response files is because of command line limitations. That is why we made it so hard to change this because it is likely to actually break the build. If you could send a patch that uses the IF and type command to echo the files that would be great. Alternatively, if you could hack a generated makefile to do the right thing, and send the diff for that, we could work on generating a makefile that would match it.
(0033859)
Rob Stewart (reporter)
2013-09-20 17:00

 That's what I was suggesting could be done, and you asked for the patch.

Anyway, if someone sets CMAKE_VERBOSE_MAKEFILE and their build breaks, that's easily documented. As things stand, if one is using a shared installation of CMake, one developer cannot get verbose output while another does not. The change in the patch allows one to set CMAKE_VERBOSE_MAKEFILE while the other doesn't.

As for the makefile changes, I'll see what I can do.
(0033860)
Bill Hoffman (manager)
2013-09-20 17:50

 I would rather not break a build if possible. You still get some information out of the VERBOSE build. Anyway, I like your idea of changing the makefile so I would rather do that, than put a potential build breaker in.
(0040849)
Daniel Richard G. (reporter)
2016-04-13 01:29

 This is a feature I'd like to see as well. The CMAKE_{START,END}_TEMP_FILE bits may be necessary to get around command-line-length limitations in Windows/DOS, but it makes debugging the build logic much harder than it ought to be.

I agree that unsetting the _TEMP_FILE variables is not a good solution, because if your build then breaks due to the command-line limitations---and I've worked in large projects where precisely this has happened---then this approach does you no good.

I would also note that controlling this with a CMake variable is not a good way to go. Who wants to re-generate their makefiles just to switch verbosity modes? No, the standard way to do this is to set a Make-level variable: VERBOSE=1, or V=1, on the NMake command line.

Bill, you asked for an example of a hacked makefile rule to implement. Here's my take, illustrated with a .c.obj rule:

    src\myprog\CMakeFiles\myprog.dir\myprog.c.obj: src\myprog\CMakeFiles\myprog.dir\flags.make
    src\myprog\CMakeFiles\myprog.dir\myprog.c.obj: E:\source\tglib\src\myprog\myprog.c
        $(CMAKE_COMMAND) -E cmake_progress_report C:\temp\myproj-build\CMakeFiles $(CMAKE_PROGRESS_1)
        @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Building C object src/myprog/CMakeFiles/myprog.dir/myprog.c.obj"
    !IF $(V) - 0
        @echo cd C:\temp\myproj-build\src\myprog ^&^& \
        @echo C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe \
     /nologo $(C_FLAGS) $(C_DEFINES) /FoCMakeFiles\myprog.dir\myprog.c.obj /FdCMakeFiles\myprog.dir\ -c C:\source\myproj\myprog\myprog.c
    !ENDIF
        cd C:\temp\myproj-build\src\myprog
        C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe @<<
     /nologo $(C_FLAGS) $(C_DEFINES) /FoCMakeFiles\myprog.dir\myprog.c.obj /FdCMakeFiles\myprog.dir\ -c C:\source\myproj\myprog\myprog.c
    <<
        cd C:\temp\myproj-build

The !IF...!ENDIF bit is the new part. That expression works for V=0, V=1, or V undefined. Note that there is a space after the last backslash in the line containing "^&^&", so that a literal backslash is printed, instead of it acting as a line-continuation character.

(Perhaps this should use the existing VERBOSE variable instead of V, but setting VERBOSE=1 already causes a lot of chaff to be printed. For my part, I'd just like to see the tool invocations, and leave all the CMake plumbing hidden.)
(0042371)
Kitware Robot (administrator)
2016-06-10 14:29

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2013-09-20 14:37 Rob Stewart New Issue
2013-09-20 15:07 Bill Hoffman Note Added: 0033852
2013-09-20 15:16 Rob Stewart File Added: Windows.cmake.patch
2013-09-20 15:16 Rob Stewart Note Added: 0033853
2013-09-20 15:21 Rob Stewart Note Added: 0033854
2013-09-20 16:23 Bill Hoffman Note Added: 0033855
2013-09-20 17:00 Rob Stewart Note Added: 0033859
2013-09-20 17:50 Bill Hoffman Note Added: 0033860
2016-04-13 01:29 Daniel Richard G. Note Added: 0040849
2016-06-10 14:29 Kitware Robot Note Added: 0042371
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team