Make it possible to use OSMesa on Android

ui/gl/gl_implementation_osmesa.h

Index: ui/gl/gl_implementation_osmesa.h
diff --git a/ui/gl/gl_implementation_linux.h b/ui/gl/gl_implementation_osmesa.h
similarity index 77%
rename from ui/gl/gl_implementation_linux.h
rename to ui/gl/gl_implementation_osmesa.h
index 31b57980327b7330ff1a3ef27588caf9ffe27870..9bce2eb72fa13b708cb692397db21d7d68ec0ce7 100644
--- a/ui/gl/gl_implementation_linux.h
+++ b/ui/gl/gl_implementation_osmesa.h
@@ -2,6 +2,9 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
+#ifndef UI_GL_GL_IMPLEMENTATION_OSMESA_
+#define UI_GL_GL_IMPLEMENTATION_OSMESA_
+
 #include "base/files/file_path.h"
 #include "base/native_library.h"
 
@@ -12,3 +15,5 @@ base::NativeLibrary LoadLibrary(const char* filename);
 base::NativeLibrary LoadLibrary(const base::FilePath& filename);

[no sievers, 2013/10/04 21:48:54]

Do the LoadLibrary function maybe fit better into gl_implementation.h/.cc?
They are not really specific to Mesa and also used to load other (e.g. EGL)
libraries.

[Peter Beverloo, 2013/10/25 15:40:55]

They feel like base/-level methods to me.  I'd prefer to limit exposure as far
as we can, or formally move them to ui/base/.

[no sievers, 2013/10/25 19:08:13]

It just felt a bit weird that gl_implementation_android.cc needs to include
gl_implementation_osmesa.h regardless of osmesa-specific functionality. Now that
I look at them, the functions don't look very useful anyways (one is a
one-liner, the other one adds a VLOG on failure), so you could probably also
just remove/inline them.

 
 }  // namespace gfx
+
+#endif  // UI_GL_GL_IMPLEMENTATION_OSMESA_