Commit graph

6 commits

Author SHA1 Message Date
Chih-Wei Huang
b0e33c2256 android: fix the building rules for Android 5.0
Android 5.0 allows modules to generate source into $OUT/gen, which will
then be copied into $OUT/obj and $OUT/obj_$(TARGET_2ND_ARCH) as necessary.
Modules will need to change calls to local-intermediates-dir into
local-generated-sources-dir.

The patch changes local-intermediates-dir into local-generated-sources-dir.
If the Android version is less than 5.0, fallback to local-intermediates-dir.

The patch also fixes the 64-bit building issue of Android 5.0.

v2 [Emil Velikov]
 - Keep the LOCAL_UNSTRIPPED_PATH variable.

Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
2015-04-22 15:53:35 +01:00
Matt Turner
d5e9426b96 build: Move src/mapi/mapi/* to src/mapi/
Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-and-Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2013-04-15 12:04:25 -07:00
Chad Versace
5154b45217 mapi: Fix Android build
The Android build was broken by
    commit ca760181b4
    Author: Kristian Høgsberg <krh@bitplanet.net>
    Date:   Fri Mar 16 12:55:40 2012 -0400

    shared-glapi: Convert to automake

The offending change was that it redefined the filepaths in sources.mak
like this:
    - FOO_FILES := bar.c
    + FOO_FILES := $(TOP)/src/mapi/mapi/bar.c
This broke the build because source filepaths in Android makefiles must be
relative to the makefile.

Ideally, this could be fixed by reverting the change in sources.mak and
making shared-glapi's Makefile.am use $(addprefix $(TOP)/src/mapi/mapi,
$(FOO_FILES)). However, automake doesn't understand builtin GNU make
functions, such as addprefix. So, it seems that automake and Android can
no longer share sources.mak.

Fix the build by duplicating the source lists from sources.mak into
Android.mk.

Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
2012-04-10 21:07:12 -07:00
Kristian Høgsberg
ca760181b4 shared-glapi: Convert to automake
This fixes a build problem where EGL links to libgbm.la, which encodes
a relative path to it's libglapi.so dependency.  The relative path
breaks when the linker tries to resolve it from src/egl/main instead
of src/gbm.  Typically we silently fall back to the system
libglapi.so, which is wrong and breaks when there isn't one.

Morale of the story: don't mix mklib and libtool.
2012-03-19 11:13:06 -04:00
Chia-I Wu
169ef48c85 android: clean up libglapi bulid rules a bit
Make the output prettier.  Make the rules reusable if we ever want to add
other modules, such as libGLESv2_mesa.
2011-11-26 11:42:01 +08:00
Chia-I Wu
ee41fc898d android: build shared glapi
This builds the shared library libglapi from shared glapi.

Reviewed-by: Chad Versace <chad@chad-versace.us>
2011-08-21 02:01:49 +08:00