773454 - WebRTC tests fail to build using visual studio 2012

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[Jim Mathies [:jimm]]

A long series of errors similar to these:

f:\Mozilla\firefox\mc\media\webrtc\trunk\testing\gtest\include\gtest/gtest-printers.h(550) : error C2977: 'std::tuple' : too many template arguments
        C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\utility(73) : see declaration of 'std::tuple'
f:\Mozilla\firefox\mc\media\webrtc\trunk\testing\gtest\include\gtest/gtest-printers.h(558) : error C2977: 'std::tuple' : too many template arguments
        C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\utility(73) : see declaration of 'std::tuple'
f:\Mozilla\firefox\mc\media\webrtc\trunk\testing\gtest\include\gtest/internal/gtest-param-util-generated.h(4017) : error C2977: 'std::tuple' : too many template arguments
        C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\utility(73) : see declaration of 'std::tuple'
        f:\Mozilla\firefox\mc\media\webrtc\trunk\testing\gtest\include\gtest/internal/gtest-param-util-generated.h(4249) : see reference to class template instantiation 'testing::internal::CartesianProductGenerator9<T1,T2,T3,T4,T5,T6,T7,T8,T9>' being compiled
f:\Mozilla\firefox\mc\media\webrtc\trunk\testing\gtest\include\gtest/internal/gtest-param-util-generated.h(4017) : error C3203: 'tuple' : unspecialized class template can't be used as a template argument for template parameter 'T', expected a real type
f:\Mozilla\firefox\mc\media\webrtc\trunk\testing\gtest\include\gtest/internal/gtest-param-util-generated.h(4017) : error C2955: 'std::tuple' : use of class template requires template argument list
        C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\utility(73) : see declaration of 'std::tuple'
f:\Mozilla\firefox\mc\media\webrtc\trunk\testing\gtest\include\gtest/internal/gtest-param-util-generated.h(4017) : error C2955: 'testing::internal::ParamGeneratorInterface' : use of class template requires template argument list
        f:\Mozilla\firefox\mc\media\webrtc\trunk\testing\gtest\include\gtest/internal/gtest-param-util.h(142) : see declaration of 'testing::internal::ParamGeneratorInterface'

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Are the problems all in gtest?

Comment 2

[Jim Mathies [:jimm]]

(In reply to Randell Jesup [:jesup] from comment #1)
> Are the problems all in gtest?

Yes, if I clip trunk/testing out of the root makefile the library builds successfully. Do we rely on these tests?

Comment 3

[(not currently active) Ted Mielczarek]

I wonder if these have been fixed in upstream gtest? If not, we can probably get them fixed.

Comment 4

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

These are caused by a change in VS2012.  Basically, variadic macros support fewer arguments in VS2012RC than they did in previous version of VS.  Defining `_VARIADIC_MAX` to be 10 might solve this issue.

From [1]:
  "Spamming out so many pair-tuple overloads, plus all of the emplacement overloads, consumed a massive amount of memory during compilation. Therefore, we reduced infinity. In Visual C++ 2008 SP1 and Visual C++ 2010, infinity was 10 (that is, "variadic" templates supported 0 to 10 arguments, inclusive). By default, infinity is 5 in Visual C++ in Visual Studio 2012 RC. This brings compiler memory consumption back to what it was in Visual C++ 2010. If you need more arguments (for example, if you have existing code that uses 6-tuples), there is an escape hatch. You can define _VARIADIC_MAX project-wide between 5 and 10 inclusive. This consumes more memory, and may require that you use the /Zm compiler option to reserve more space for pre-compiled headers."

[1] http://msdn.microsoft.com/en-us/library/hh567368%28v=vs.110%29.aspx

Comment 5

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Attachment: Patch v1

The attached patch seems to fix my local builds.  Ted; are you the right person to review this?

Comment 6

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

This has run through tryserver:
  https://tbpl.mozilla.org/?tree=Try&rev=6d7d2c9d94d4

Comment 7

[(not currently active) Ted Mielczarek]

Comment on attachment 642032 [details] [diff] [review]
Patch v1

Review of attachment 642032 [details] [diff] [review]:
-----------------------------------------------------------------

This seems reasonable. We'll want to get this upstream, but I'm not sure what our process is there currently.

Comment 8

[Timothy B. Terriberry (:derf)]

(In reply to Ted Mielczarek [:ted] from comment #7)
> This seems reasonable. We'll want to get this upstream, but I'm not sure
> what our process is there currently.

http://www.webrtc.org/reference/contributing

Comment 9

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

I filed this issue at the webrtc site and attached the patch from this bug (modified to apply correctly using the gclient set of tools):
  http://code.google.com/p/webrtc/issues/detail?id=683

Comment 10

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Pushed to inbound and marking as "leave open": We'll want to back out this patch when an upstream fix is available.

https://hg.mozilla.org/integration/mozilla-inbound/rev/41308088db55

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

Thanks tim - I'll track it

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/41308088db55

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

It appears webrtc.org won't be taking this, so we'll need to carry the patch in our tree.  Closing.

Comment 14

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

I got an email saying that this has been fixed upstream [1]. Do we now want to back out the fix for this?

[1] http://code.google.com/p/webrtc/issues/detail?id=683