Add support for khronos gl-cts using its drawElements apis

build/common.gypi

 # Copyright (c) 2012 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # IMPORTANT:
 # Please don't directly include this file if you are building via gyp_chromium,
 # since gyp_chromium is automatically forcing its inclusion.
 {
   # Variables expected to be overriden on the GYP command line (-D) or by
   # ~/.gyp/include.gypi.
@@ skipping 1360 matching lines @@
 
     # TODO(thakis): Make this a blacklist instead, http://crbug.com/101600
     'enable_wexit_time_destructors%': 0,
 
     # Build libpeerconnection as a static library by default.
     'libpeer_target_type%': 'static_library',
 
     # Set to 1 to compile with the OpenGL ES 2.0 conformance tests.
     'internal_gles2_conform_tests%': 0,
 
+    # Set to 1 to compile with the OpenGL ES 3.x conformance tests.
+    'internal_khronos_conform_tests%': 0,

[piman, 2014/09/10 20:12:50]

Does this and internal_gles2_conform_tests need to be separate? I'd assume
whoever has access to one has access to the other one. It'd be simpler to only
have one of these.

[U. Artie Eoff, 2014/09/10 22:12:59]

I think the "gles2" in the name "internal_gles2_conform_tests" is too narrow and
implies only es2 tests.  We want to add es3 tests and future versions later.  We
could merge these, I suppose, into one form eventually; one which doesn't
constrict meaning so much (like internal_khronos_conform here).  But I'd rather
be able to compile one and not the other.  I think the idea behind this is to
incrementally ramp up with the new drawElements support and phase out the old. 
This requires having both for the transition phase.

[Ken Russell (switch to Gerrit), 2014/09/11 00:03:26]

Understood that the duplication may be necessary for the time being due to major
differences between the test harnesses. However the naming convention here is
confusing. Since you're explicitly targeting the ES 3.x tests can you please
replace 'khronos' with 'gles3' throughout this CL?

[U. Artie Eoff, 2014/09/11 01:09:19]

Well... the idea is to target all the tests actually.  That is, to target ES2,
ES30, ES31, and any future ES versions (and who knows, maybe GL21 thru GL44 and
beyond).  All versions can be targeted in one [binary] instance using this new
API.  That is why I chose the more generic naming convention.  In fact, this
particular patch only targets the ES2 tests at the moment, the same as the
gles2_conform_support.  The main difference is it's using the new APIs so that
we can trivially add the other ESx tests later without being constrained by
naming conventions.

[Ken Russell (switch to Gerrit), 2014/09/11 01:25:17]

I still think a more targeted name is appropriate. If not gles3, then gles, or
khronos_gles, or something. If some future API comes around under Khronos'
umbrella that isn't tested in this particular harness, a naming conflict with
this would be unfortunate. What do you think?

[U. Artie Eoff, 2014/09/11 16:50:52]

Yeah, I'd be fine using "khronos_gles_conform".  Or, what about "khronos_glcts"?
 GL-CTS is the true project name of their entire conformance suite afterall (see
their cmake file).  It does make a shorter prefix and also is a bit more of a
targeted name than my original.  If no one likes that, I'll go with the former.

[Ken Russell (switch to Gerrit), 2014/09/11 17:40:04]

Both sound fine. If khronos_glcts is closer to the real name of the project,
let's go with that.

+
     # Set to 1 to compile the filter fuzzer.
     'internal_filter_fuzzer%': 0,
 
     # NOTE: When these end up in the Mac bundle, we need to replace '-' for '_'
     # so Cocoa is happy (http://crbug.com/20441).
     'locales': [
       'am', 'ar', 'bg', 'bn', 'ca', 'cs', 'da', 'de', 'el', 'en-GB',
       'en-US', 'es-419', 'es', 'et', 'fa', 'fi', 'fil', 'fr', 'gu', 'he',
       'hi', 'hr', 'hu', 'id', 'it', 'ja', 'kn', 'ko', 'lt', 'lv',
       'ml', 'mr', 'ms', 'nb', 'nl', 'pl', 'pt-BR', 'pt-PT', 'ro', 'ru',
@@ skipping 4393 matching lines @@
     # settings in target dicts.  SYMROOT is a special case, because many other
     # Xcode variables depend on it, including variables such as
     # PROJECT_DERIVED_FILE_DIR.  When a source group corresponding to something
     # like PROJECT_DERIVED_FILE_DIR is added to a project, in order for the
     # files to appear (when present) in the UI as actual files and not red
     # red "missing file" proxies, the correct path to PROJECT_DERIVED_FILE_DIR,
     # and therefore SYMROOT, needs to be set at the project level.
     'SYMROOT': '<(DEPTH)/xcodebuild',
   },
 }