Bug 39873 - gen-tests MSVC build failure
Summary: gen-tests MSVC build failure
Status: CLOSED FIXED
Alias: None
Product: piglit
Classification: Unclassified
Component: infrastructure (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Windows (All)
: medium blocker
Assignee: Paul Berry
QA Contact: Eric Anholt
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-05 19:57 UTC by Vinson Lee
Modified: 2011-08-18 19:32 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
nmake.log (35.16 KB, text/plain)
2011-08-05 19:57 UTC, Vinson Lee
Details

Description Vinson Lee 2011-08-05 19:57:45 UTC
Created attachment 49982 [details]
nmake.log

The generated list of test names is too long for MSVC.
Comment 1 Vinson Lee 2011-08-05 20:02:04 UTC
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>
Comment 2 Paul Berry 2011-08-06 17:46:20 UTC
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.
Comment 3 Vinson Lee 2011-08-08 19:42:41 UTC
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.
Comment 4 Paul Berry 2011-08-09 17:25:38 UTC
(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.
Comment 5 Vinson Lee 2011-08-09 17:41:26 UTC
(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.
Comment 6 Paul Berry 2011-08-10 12:03:25 UTC
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.
Comment 7 Paul Berry 2011-08-10 14:40:04 UTC
Fixed in commit 1e77364946e50d087a09ef588f8b90b502019838.
Comment 8 Vinson Lee 2011-08-18 19:32:00 UTC
piglit: 8101d45b76523be5a1f065eb7fdc3a6e236e53d0 (master)

Verified fixed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.