Add nanobench, a fresh look at our microbenchmark harness.

gyp/bench.gyp

Index: gyp/bench.gyp
diff --git a/gyp/bench.gyp b/gyp/bench.gyp
index 9089bf8bc07d04a728ef183747a2623bb6504573..cbbf27f9a7017a5251fc4895952049da84a078b8 100644
--- a/gyp/bench.gyp
+++ b/gyp/bench.gyp
@@ -9,13 +9,10 @@
       'target_name': 'bench',
       'type': 'executable',
       'dependencies': [
-        'etc1.gyp:libetc1',
         'flags.gyp:flags',
         'jsoncpp.gyp:jsoncpp',
         'skia_lib.gyp:skia_lib',

[djsollen, 2014/06/25 19:52:40]

if skia_lib is pulled in by the bench gypi then we can remove it from here as
well.

[mtklein, 2014/06/25 20:28:08]

Let me hold off on this for another CL.  I actually would prefer to reorganize
our GYPs pretty much the other way, so that each of these binaries could build
as an empty but functioning shell app if you commented out the includes.  It'd
be nice if the tool specified the tool's deps and the include brought in the
include's deps.

         'tools.gyp:crash_handler',
-        'tools.gyp:resources',
-        'tools.gyp:sk_tool_utils',
         'tools.gyp:timer',
       ],
       'sources': [
@@ -27,28 +24,27 @@
         '../bench/benchmain.cpp',
       ],
       'conditions': [
-        ['skia_gpu == 1',
-          {
-            'include_dirs' : [
-              '../src/gpu',
-            ],
-            'dependencies': [
-              'gputest.gyp:skgputest',
-            ],
-          },
-        ],
-        ['skia_android_framework == 1',
-          {
-            'libraries': [
-              '-lskia',
-            ],
-          },
-        ],
+        ['skia_android_framework == 1', {
+          'libraries': [ '-lskia' ],
+        }],
       ],
       'includes': [
         'bench.gypi',
         'gmslides.gypi',
       ],
     },
+    {
+      'target_name': 'nanobench',
+      'type': 'executable',
+      'sources': [
+        '../bench/nanobench.cpp',

[tfarina, 2014/06/25 20:06:25]

NanoBenchMain.cpp?

otherwise can it be either nanobench_main.cpp or nanobenchmain.cpp

[mtklein, 2014/06/25 20:28:08]

I prefer nanobench.cpp.  It compiles into a binary named nanobench.  There's no
Nanobench class to collide with.  Why complicate things?

[tfarina, 2014/06/25 21:08:04]

I don't understand why you call naming a file nanobench_main.cpp or
nanobenchmain.cpp, complicate anything. If you come later and add a class
NanoBench then that will complicate things. That is what already happens with
dump_record.

+      ],
+      'includes': [ 'bench.gypi' ],
+      'dependencies': [
+        'flags.gyp:flags',
+        'tools.gyp:crash_handler',
+        'tools.gyp:timer',
+      ],
+    },
   ],
 }