Make the build control what library(/ies) to load

content/public/android/java/src/org/chromium/content/app/NativeLibraries.java

Index: content/public/android/java/src/org/chromium/content/app/NativeLibraries.java
diff --git a/content/public/android/java/src/org/chromium/content/app/NativeLibraries.java b/content/public/android/java/src/org/chromium/content/app/NativeLibraries.java
new file mode 100644
index 0000000000000000000000000000000000000000..8f04eccf9d7cd16e484f10bcc0a136ab19b34dce
--- /dev/null
+++ b/content/public/android/java/src/org/chromium/content/app/NativeLibraries.java
@@ -0,0 +1,13 @@
+// Copyright (c) 2012 The Chromium Authors. All rights reserved.

[joth, 2013/03/26 19:16:26]

nix (c)
2013

+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.content.app;
+
+public class NativeLibraries {

[joth, 2013/03/26 19:16:26]

I'm wary about giving this class the .java extension (or locating it in the
java/src tree). While you've kept it syntactically compatible with java, it can
lead to even greater confusion if debugger etc. pick up this source rather than
the 'real' source for the file.

thoughts..
- this seems kind-of similar to the R.java generated resources, would it fit
better into that sort of a generation flow?
- does it need to be public?

[cjhopman, 2013/03/26 21:15:37]

It has to be syntactically compatible with Java as it is used when compiling
content_java.
This file is needed when compiling content_java (since content_java refers to
this libraries variable). In the R.java workflow, we similarly need R.java files
like this one (without values) when compiling libraries, but in that case we
have to wait until build time to generate the temporary R.java and so it is
placed in an output directory.

The only difference between this file and the real source is that the real
source is that the real source has libraries assigned to a constant value. Any
tool that looks at the actual path of the library included in the .apk should be
able to find the real source, and tools that just use package+class wouldn't be
able to distinguish between the different versions of the real source for
different Apks.

The only real difference from the R.java workflow is that this file is directly
in the content_java src directory. It is simple to move it somewhere else if
you're convinced it will have benefits for debugger/ide/etc.
No, it doesn't.

+    // This is the list of native libraries to be loaded by LibraryLoader.java.
+    // The build system creates a version of this file with the placeholder below replaced with a
+    // constant list of the correct libraries to load (in the correct order).
+    static String[] libraries /*****/;

[bulach, 2013/03/26 19:02:15]

I like the idea of injecting this, but not quite like the entirely new
templating concept with this magic placeholder :)

we already have support for generating files using the c-pre-processor, so this
would be simplified by:
- generate a file with say:

#define USE_LIBRARY "foo"
#define USE_LIBRARY "bar"
#define USE_LIBRARY "zoo"


then have it here:
static String libraries = {
#define USE_LIBRARY(lib) lib, 
#include "auto_generated_libs.h"
#undef USE_LIBRARY
};

check "net_errors_java" target in net/net.gyp

[cjhopman, 2013/03/26 21:15:37]

I had considered using java_cpp_template.gypi but I think that'll actually make
this (much) more complex.

First, there's no need for the USE_LIBRARY macro, the generated file can contain
the actual values rather than:
USE_LIBRARY("foo")
USE_LIBRARY("bar")
USE_LIBRARY("zoo")

But then, you've just traded one magic placeholder ('/****/' for another
'#include "auto_generated_libs.h"'). And you now have to jump through gyp hoops
to use java_cpp_template.gypi or (slightly cleaner) use a new gyp action that
calls gcc. At that point, it's simpler to call gcc directly in from the python
script that generates auto_generated_libs.h, and now you've written your list to
a file and have a subprocess call to gcc to preprocess the files instead of just
using python's string.replace().

Also note that, when compiling content_java, you need a different version of the
file and since the c-preprocessor version can't be valid Java, you either have
to use two files, a dummy java file and the template file, or you have to
generate the file for content_java at build time (with an empty
"auto_generated_libs.h").

+}
+