This change supports Android NDK.

make: support Android NDK

This change generates LOCAL_XXX variable definitions for Android NDK.  These variable definitions and make rules do nothing for non-Android applications.  But, when the Makefile is invoked by 'ndk-build' command of Android NDK, it works nicely with LOCAL_XXX variables.

Patch by Yuki Shiino <yukishiino@google.com>;.

Committed: http://code.google.com/p/gyp/source/detail?r=919

[Mark Mentovai, 2011-04-26 19:15:28]

Evan owns the GYP make generator, I’m delegating this one to him.

Evan, FYI, this is one of a series of patches from Yuki. The others are
http://codereview.chromium.org/6904020/ and
http://codereview.chromium.org/6883158/ in case you’re interested.

[tony, 2011-04-26 19:21:09]

FWIW, it seems strange for android specific variables in gyp (OTOH, there are
probably some chromium specific variables already there).

Maybe we should make it possible for a gyp variable to pass through to the
Makefile.

[Evan Martin, 2011-04-26 19:23:49]

I'm unfamiliar with the Android NDK.  Are these LOCAL_* variables special in its
build system?  How do they get propagated into this Makefile -- via the
environment?

Where does "my-dir" come from?  I don't see it in the Make manual.

[Yuki Shiino, 2011-04-27 02:53:13]

docs/ANDROID-MK.TXT in Android NDK explains how to write a user's makefile, and
it must be better than mine.  But let me try to explain it.
Also see: http://developer.android.com/sdk/ndk/

'ndk-build' command in Android NDK invokes GNU Make with NDK's makefile.  That
makefile defines CLEAR_VARS, BUILD_EXECUTABLE, etc., which are paths to NDK's
other makefiles.  After the initialization of those variable, the makefile
includes a user's makefile.  The user's makefile is supposed to have the
following:

include $(CLEAR_VARS)
LOCAL_XXX = ...
include $(BUILD_EXECUTABLE)

The NDK's makefile takes care of the rest.
CLEAR_VARS resets all LOCAL_XXX variables for the next use, and
BUILD_EXECUTABLE, etc. generates necessary make rules based on LOCAL_XXX.

Android NDK (i.e. Makefile) also provides a few API functions and "my-dir" is
one of them.  "my-dir" returns the absolute path of the current makefile, and
LOCAL_PATH must have it.

[Yuki Shiino, 2011-04-27 03:11:38]

On 2011/04/26 19:21:09, tony wrote:
> Maybe we should make it possible for a gyp variable to pass through to the
> Makefile.

That's a good idea, and I'd like to have that feature, too, but we'd like more
functionality.
IMHO, simple variable definition wouldn't work for the following requirements.

1. LOCAL_CFLAGS, etc. should vary according to BUILDTYPE.
e.g. have -O2 when BUILDTYPE=Release.

2. LOCAL_CPP_EXTENSION should be detected automatically.
e.g. .cpp or .cxx or .cc

3. LOCAL_SRC_FILES should be filtered by Compilable.

4. LOCAL_STATIC_LIBRARIES must have all the dependencies (not only direct
dependencies but also grandchildren, etc.), and it should be processed by GYP.

My patch does more than simple variable definitions.  If we move this feature
into .gyp files, GYP must have more powerful features.

[Evan Martin, 2011-05-02 23:11:06]

Sorry!  I forgot about this change!

I am concerned all this extra stuff in the Makefile will slow down the normal
Chrome developers.  Would you mind putting this behind a flag?

If you pass a flag to gyp of the form
  -Gfoo=bar
then that flag will be available in generator_flags inside GenerateOutput:
  if 'foo' in generator_flags:
    assert generator_flags['foo'] == bar

You can use that to conditionally generate this additional info.

[Yuki Shiino, 2011-05-03 18:00:24]

On 2011/05/02 23:11:06, Evan Martin wrote:
> Sorry!  I forgot about this change!
> 
> I am concerned all this extra stuff in the Makefile will slow down the normal
> Chrome developers.  Would you mind putting this behind a flag?
> 
> If you pass a flag to gyp of the form
>   -Gfoo=bar
> then that flag will be available in generator_flags inside GenerateOutput:
>   if 'foo' in generator_flags:
>     assert generator_flags['foo'] == bar
> 
> You can use that to conditionally generate this additional info.

Thanks for the review.
I've updated the code to use a flag -Gandroid_ndk_version=r5 (or something).
The current implementation doesn't care about the actual version, though.
Only if the flag is defined, the new rules are generated.

[Evan Martin, 2011-05-03 18:22:09]

LGTM, perfect, thanks!

[Evan Martin, 2011-05-03 18:24:18]

On 2011/05/03 18:22:09, Evan Martin wrote:
> LGTM, perfect, thanks!

(I will commit this for you.)