Bug 39873

http://msdn.microsoft.com/en-us/library/23bz2yst%28VS.100%29.aspx

<quote>
expanded command line 'commandline' too long

After macro expansion, the given command line exceeded the limit on length of command lines for the operating system.

MS-DOS permits up to 128 characters on a command line.

If the command is for a program that can accept command-line input from a file, change the command and supply input from either a file on disk or an inline file. For example, LINK and LIB accept input from a response file.
</quote>

I'd be happy to help track this down, especially since I contributed the test generation script that provokes the problem, but I'll need some assistance figuring out how to build Piglit on Windows.  I installed a copy of Windows Vista in a VM, installed git and cmake, and Visual C++ 2010 Express.  Should this be sufficient to build Piglit?  When I try typing "cmake ." from the piglit dir, I get:

CMake Warning at CMakeLists.txt:2 (PROJECT):
  To use the NMake generator, cmake must be run from a shell that can use the
  compiler cl from the command line.  This environment does not contain
  INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to
  work.


Piglit's README, sadly, doesn't contain any special instructions for Windows.

It's been a few years since I've developed for Windows, and though I'm sure I could bumble through and figure it out eventually, I'd appreciate some pointers from people who build Piglit on Windows all the time.

Thanks.

Are you running CMake from the Visual Studio shell? If not, there's a Visual Studio shell at All Programs->Microsoft Visual Studio 2010->Visual Studio Tools->Visual Studio Command Prompt.

(In reply to comment #3)
> Are you running CMake from the Visual Studio shell? If not, there's a Visual
> Studio shell at All Programs->Microsoft Visual Studio 2010->Visual Studio
> Tools->Visual Studio Command Prompt.

Thanks for the pointer, Vinson.  I still haven't worked out how to do a complete build under Windows (cmake can't find the TIFF and PNG libraries, even though I've installed them, sigh), but by disabling the parts of the build that are giving me problems, I was able to reproduce and track down the bug.

The problem is occurring when cmake tries to print a diagnostic message informing the user that it's running the test generator.  The diagnostic message takes the form "Generating <file1>, <file2>, ...".  Since cmake knows the names of all 462 output files, it tries to print them all out on one line.  The way cmake prints its diagnostic messages is to have nmake invoke "cmake.exe -E cmake_echo_color --switch= --blue --bold <message>", resulting in a command line that is too big for nmake to handle.

After some experimentation and reading of manuals, I think this all boils down to a newbie mistake I made when adding the test generation code to generated_tests/CMakeLists.txt.  I explicitly precomputed all the outputs of the test generation code and fed them into add_custom_command() so that dependency analysis would ensure that the files were generated at the right time.  But that was unnecessary because the generated files aren't needed at build time, so it doesn't matter when they're generated.  And it led to this failure by causing cmake to try to print out the list of files as a huge diagnostic message.

I believe I can change the make script so that rather than precomputing all the outputs of the test generation code and feeding them into dependency analysis, it just ensures that the generator script runs at some point during the build process.

I'll work on this first thing tomorrow morning.

(In reply to comment #4)
> Thanks for the pointer, Vinson.  I still haven't worked out how to do a
> complete build under Windows (cmake can't find the TIFF and PNG libraries, even
> though I've installed them, sigh), but by disabling the parts of the build that
> are giving me problems, I was able to reproduce and track down the bug.

If CMake does not find the location of TIFF and PNG, you can try setting them explicitly through 'cmake-gui.exe .'.

Goto Advanced View.
Set PNG_LIBRARY to point to the fully-qualified name of libpng.lib, likewise with TIFF_LIBRARY and libtiff.lib.

Set PNG_PNG_INCLUDE_DIR and TIFF_INCLUDE_DIR to the fully-qualified directory names.

Similar actions may be needed for ZLIB.

I've sent a patch to the Piglit list which I believe fixes this bug.  I've verified that I can now build Piglit under Windows (though I can't actually run the tests, because I'm using a VM).

Vinson (or anyone else who does actual testing under Windows), I'll be glad to push the patch as soon as I hear that it works for you.

Fixed in commit 1e77364946e50d087a09ef588f8b90b502019838.

piglit: 8101d45b76523be5a1f065eb7fdc3a6e236e53d0 (master)

Verified fixed.