Linux sandbox: Make the test run on Android as Native executable

sandbox/linux/sandbox_linux.gypi

Index: sandbox/linux/sandbox_linux.gypi
diff --git a/sandbox/linux/sandbox_linux.gypi b/sandbox/linux/sandbox_linux.gypi
index 2fac989ab6397f764ee6ad0be81e0f9da6333b31..5365fbbc723da764748d66f5c8aa0019996a66f0 100644
--- a/sandbox/linux/sandbox_linux.gypi
+++ b/sandbox/linux/sandbox_linux.gypi
@@ -4,6 +4,9 @@
 
 {
   'variables': {
+    'sandbox_linux_unittests_apk_target': 0,
+    # Whether to build the android test as an APK or an ELF executable.
+    'build_android_jni_test': 1,

[jln (very slow on Chromium), 2013/01/30 00:04:25]

This is a poor solution to keep both APK and non APK options available.

I tried everything I could think of:
- make a separate "files" target of type none and then a shared_library and an
executable target.
- dynamically detect via sandbox_linux_unittests_apk_target what we were trying
to currently build.

Everything seems to fail in one way or another. I think there is a lot of magic
going on with unit tests that I don't know about.

For instance if not directly including unit test related files (but instead
adding a dependency that will include these files), the tests don't run.

[Agrawal, 2013/01/30 01:43:08]

I am not sure why you are doing this. If you want to build executable by
default, you can just change the type to executable, and when you need to build
sharedlibrary you change it back to gtest_target_type locally.
If you want to build shared_library by default, you can keep gtest_target_type
and modify the gyp variable during the gyp step when you need to build an
executable. You wont even need to modify any file in this case.

I am sorry I fail to understand the reasoning here.

[jln (very slow on Chromium), 2013/01/30 01:56:29]

There must be something I don't know. Are you saying that there is a command
line option that I can use to set gtest_target_type ?

What I was trying to achieve (and failed) was to have one target
sandbox_linux_unittests_apk that is the APK with JNI etc and one target
sandbox_linux_unittests that is a normal ELF file.

So that one could easily build one on the other, depending on the chosen target.

It's actually very hard, surprisingly to have two different targets that include
the same tests.

[Agrawal, 2013/01/30 02:17:05]

IIRC, you can modify GYP_DEFINES in your environment to change
gtest_target_type. 

Actually strike that, gtest_target_type no longer comes from a gyp define after
this CL.
http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?view=diff&r...
It should be doable by having two targets:
sandbox_linux_unittests: type executable
sandbox_linux_unittests_shlib: type sh_lib, will depend on
../testing/android/native_test.gyp:native_test_native_code

the _apk target will depend on the shlib target.


both can share the same source files by having a test_sources.gypi (which will
list all the source files). 

[jln (very slow on Chromium), 2013/01/30 02:27:51]

I tried that (without an external gypi file though). I tried both with type
"none", or by making a small static library.
It doesn't work, the executable doesn't see any tests after that. I *think* it's
because there is some magic that finds out that it's not necessary to link
certain files to the executable (since strictly speaking there are no unmatched
symbols at link time in the case of tests). But I'm really not sure what
happens.

In the meantime, the most important change for me would be a way to run the
tests with --exe (which is independent from this change), as I commented on the
bug.

     'conditions': [
       ['OS=="linux"', {
         'compile_suid_client': 1,
@@ -66,7 +69,6 @@
     },
     {
       'target_name': 'sandbox_linux_unittests',
-      'type': '<(gtest_target_type)',
       'dependencies': [
         'sandbox',
         '../testing/gtest.gyp:gtest',
@@ -81,6 +83,11 @@
         '../..',
       ],
       'conditions': [
+        [ 'build_android_jni_test==1', {
+          'type': '<(gtest_target_type)',
+        }, {
+          'type': 'executable',
+        }],
         [ 'compile_suid_client==1', {
           'sources': [
             'suid/client/setuid_sandbox_client_unittest.cc',
@@ -96,10 +103,10 @@
             'seccomp-bpf/syscall_unittest.cc',
           ],
         }],
-        ['OS == "android" and gtest_target_type == "shared_library"', {
+        [ 'OS == "android" and gtest_target_type == "shared_library"', {
           'dependencies': [
             '../testing/android/native_test.gyp:native_test_native_code',
-          ]
+          ],
         }],
       ],
     },
@@ -214,7 +221,6 @@
         '..',
       ],
     },
-
   ],
   'conditions': [
     # Strategy copied from base_unittests_apk in base/base.gyp.
@@ -223,15 +229,16 @@
         {
         'target_name': 'sandbox_linux_unittests_apk',
         'type': 'none',
-        'dependencies': [
-          'sandbox_linux_unittests',
-        ],
         'variables': {
+          'sandbox_linux_unittests_apk_target': 1,

[Agrawal, 2013/01/30 01:43:08]

What does this accomplish?

[jln (very slow on Chromium), 2013/01/30 01:56:29]

It's not used at the moment. I was fiddling with it when trying to accomplish
what I described above. I kept it around, because it's a fairly standard thing
that many targets define anyways.

[Agrawal, 2013/01/30 02:17:05]

I still do not understand this. these variables are read by the included gyp
template apk_test.gypi
Can you point to another such usage of this?

           'test_suite_name': 'sandbox_linux_unittests',
           'input_shlib_path':
               '<(SHARED_LIB_DIR)/<(SHARED_LIB_PREFIX)sandbox_linux_unittests'
               '<(SHARED_LIB_SUFFIX)',
         },
+        'dependencies': [
+          'sandbox_linux_unittests',
+        ],
         'includes': [ '../../build/apk_test.gypi' ],
         }
       ],