8

Very simple question, hoping for a very simple answer. I've been looking at a lot of people's android.mk files and have noticed this line. I had no documentation on it within my NDK's docs (at least find . -name "*.txt" | xargs grep "LOCAL_EXPORT_C_INCLUDES" came up with nothing). This was the only documentation I've read on it...goes way over my head...

Part 2: Am I correct in my assumption that I will need this line to use a pre-built shared library with another module? Thanks guys (and gals)

III. Exporting headers for prebuilt libraries:

The example above was called 'naive' because, in practice, the code in foo-user.c is going to depend on specific declarations that are normally found in a header file distributed with the prebuilt library (e.g. "foo.h").

In other words, foo-user.c is going to have a line like:

include < foo.h >

And you need to provide the header and its include path to the compiler when building the foo-user module. A simple way to deal with that is to use exports in the prebuilt module definition. For example, assuming that a file "foo.h" is located under the 'include' directory relative to the prebuilt module, we can write:

`include $(CLEAR_VARS)

LOCAL_MODULE := foo-prebuilt

LOCAL_SRC_FILES := libfoo.so

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include

include $(PREBUILT_SHARED_LIBRARY)`

The LOCAL_EXPORT_C_INCLUDES definition here ensures that any module that depends on the prebuilt one will have its LOCAL_C_INCLUDES automatically prepended with the path to the prebuilt's include directory, and will thus be able to find headers inside that.

URL: http://www.srombauts.fr/android-ndk-r5b/docs/PREBUILTS.html

Mogsdad
  • 44,709
  • 21
  • 151
  • 275
  • 2
    Yes. you are correct in your assumption. Make sure your `LOCAL_EXPORT_C_INCLUDES` points to the includes directory for the .so file. YOU'RE WELCOME, ME! –  Jul 06 '11 at 15:20

1 Answers1

13

The following explanation for the LOCAL_EXPORT_* variables in ANDROID-MK.html in the docs folder of the r6 NDK:

LOCAL_EXPORT_CFLAGS
Define this variable to record a set of C/C++ compiler flags that will
be added to the LOCAL_CFLAGS definition of any other module that uses
this one with LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES.

For example, consider the module 'foo' with the following definition:

   include $(CLEAR_VARS)
   LOCAL_MODULE := foo
   LOCAL_SRC_FILES := foo/foo.c
   LOCAL_EXPORT_CFLAGS := -DFOO=1
   include $(BUILD_STATIC_LIBRARY)

And another module, named 'bar' that depends on it as:

   include $(CLEAR_VARS)
   LOCAL_MODULE := bar
   LOCAL_SRC_FILES := bar.c
   LOCAL_CFLAGS := -DBAR=2
   LOCAL_STATIC_LIBRARIES := foo
   include $(BUILD_SHARED_LIBRARY)

Then, the flags '-DFOO=1 -DBAR=2' will be passed to the compiler when
building bar.c

Exported flags are prepended to your module's LOCAL_CFLAGS so you can
easily override them. They are also transitive: if 'zoo' depends on
'bar' which depends on 'foo', then 'zoo' will also inherit all flags
exported by 'foo'.

Finally, exported flags are not used when building the module that
exports them. In the above example, -DFOO=1 would not be passed to the
compiler when building foo/foo.c.

LOCAL_EXPORT_CPPFLAGS
Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only.

LOCAL_EXPORT_C_INCLUDES
Same as LOCAL_EXPORT_CFLAGS, but for C include paths.
This can be useful if 'bar.c' wants to include headers
that are provided by module 'foo'.

Heefan
  • 385
  • 2
  • 8
IronMensan
  • 6,761
  • 1
  • 26
  • 35
  • 6
    What a shame it does not work as advertised. In my case, in the library I am importing, I have "LOCAL_EXPORT_C_INCLUDES" for its headers. But for the library I am building, I still have to specify the same headers previously specified in "LOCAL_EXPORT_C_INCLUDES" because they are not included... This modified build system absolutely sucks. – jww Sep 04 '14 at 18:36
  • @jww Is this for building with the AOSP source tree? Then you need `LOCAL_EXPORT_C_INCLUDE_DIRS` instead of `LOCAL_EXPORT_C_INCLUDES`... – Erlkoenig Feb 05 '20 at 12:42