GitLab

GCC is deprecated, so why is it still the default testing toolchain?

Change-Id: I6540370e5917b5b7e74f2869b4ab8d177e4ef68f

Not clear that this feature will be happening after all...

Change-Id: I0a8a5a5be31b12da2fdcb0a0a39fc96d9bad7d18

* changes:
  Don't strip out .pyd files.
  Remove unused package-release.sh script.

Windows finds it useful when we actually ship Python's compiled code.

Bug: http://b/26875911
Change-Id: Ib2179ef05d4224314ee253fa73c1dbeedd08415b

Change-Id: Ic1b73e95ba9ce5e0926e6ddd61412ab899d0f10c

Change-Id: I658d167a9325696a4521565d2416cebedae1f0f6

Change-Id: Ifcb1c8181d72dc35f09ceca77b5be0b6dee57b91

Rebase went wrong and the definition of is_arm ended up in a patch
above its first use.

Change-Id: I641ac8301e541c6308ca0a1aea032e406008e6f1

Stale files getting packaged has been screwing us over for a while. Blow
away the temp directory before each build to avoid this.

Bug: http://b/25457900
Bug: http://b/26874549
Change-Id: If39c97be1a30cec181397fb8959834bada96d2e6

Change-Id: I53d264aec954d4c93c1cf7f68a796452628ccb24

Bug: http://b/26875911
Change-Id: Ie8f5edcca6755cf8a74b1db7bf1af23773427c30

* changes:
  Add a test for unwinder compatibility in libc++.
  Fix exception unwinding in the ARM libc++ tests.
  Build libc++abi components as separate libraries.
  Link libandroid_support with libc++_static.
  Build libc++ with ndk-build instead of bash.

The libgcc and LLVM unwinders like to fight. This test will fail if
the unwinder is not linked to be tolerant of this.

Bug: http://b/26194502
Change-Id: I0d03f67edae1e53dac44fff3557666eb08e77a4a

Now that we have a separate libunwind library, we can link it in the
proper order. Doing so will fix all the unwinding failures in the
libc++ tests.

With this, most of the remaining test failures (at least for
armeabi-v7a) are mostly locale failures, which are expected because
we don't support non-en_US locales.

Bug: http://b/26194502
Change-Id: I9e37476e10fce06521b15ba45c9d99cefdc7cba2

For exception unwinding to work properly on ARM, we need to make sure
we're using the LLVM unwinder everywhere. To do this, we need to link
it into each object. As such, we need to build it as a separate
library rather than including the sources in libc++. Do the same with
libc++abi while we're at it since this makes the makefiles more
tractable.

Bug: http://b/26194502
Change-Id: I96ebc4edfcbda048689fc6f0d87d0651cb4dc8e4

When using build-cxx-stl.sh, we build the sources of
libandroid_support into libc++_static.a. Rebuilding libc++_static
from source (via FORCE_BUILD_LIBCXX) did not do this, and
unfortunately ndk-build doesn't support LOCAL_WHOLE_STATIC_LIBRARIES
for BUILD_STATIC_LIBRARY like the platform does.

An alternative approach would be to do away with libandroid_support.a
and just include those sources in libc++_static.a. Given the eventual
goal of having a compatibility library similar to libandroid_support
that is used for everything, not just libc++, keeping them separate
is probably a better option.

Change-Id: I0def1c9b109ae09790f8fdfdbd8ddb2918692705

Before this patch we had to maintain two sets of build rules for
libc++: build-cxx-stl.sh and Android.mk. This changes the prebuild
step from using the shell script to just invoking ndk-build.

For one, this means that anyone using LIBCXX_FORCE_REBUILD will
actually get a reliable result, as it's the same way we built it.

It's also quite a bit faster. It now takes only 45 seconds to build
all 8 ABIs, whereas before this patch it took 3 minutes and 15
seconds. Aside from the cost of building everything, we also benefit
from dependency checking now since we store the intermediate files in
a reliable location, which means that a null build doesn't take long
(it still takes some time because we have to run the packaging step).

Now that this has been done for libc++, we could also do this for
stlport. It may not be worth the effort, however, since that's not
being actively worked on.

Note that this patch also drops the prebuilt ARM (non-thumb)
libraries. There wasn't actually any way to use them, so there's
nothing lost here.

Change-Id: I8602f0fd3a23a2938cdc5be19d0714d5567ce6fc

Bug: http://b/26403333
Change-Id: Ia776b21f660d653ecd2e35e4c810ece9d0e4028f

* changes:
  Add support for NDK_NEW_TOOLCHAINS_LAYOUT.
  Add support for NDK_TOOLCHAINS_ROOT.
  Move STL support packaging up a level.

* changes:
  Make path functions in build_support more useful.
  Work around vim's stupidity.

If set to "true" in the environment, ndk-build will expect toolchains
to be install as toolchains/$HOST/$TOOLCHAIN instead of
toolchains/$TOOLCHAIN/prebuilt/$HOST.

Change-Id: Ie0fb6b48fb5fbeb99bcd3560b2cd3e7224123ae8

This mirrors NDK_PLATFORMS_ROOT, which allows the user to point
ndk-build at a platforms tree that is not in the normal location
relative to ndk-build.

This is particularly helpful if we want to use prebuilt toolchains for
building an NDK module. Specifically, we will use this to build libc++
using ndk-build instead of the old build-cxx-stl.sh and maintaining
two sets of build rules.

Change-Id: I137b1239ebc8068ab63e2fdaa95aff68466e326b

The STL support libraries were being packaged as a part of
build-cxx-stl.sh. That is unnecessary. Since build-cxx-stl.sh isn't
long for this world, pull them up into checkbuild.py.

Change-Id: I26095a2d30b841fa66598270007e74b96f1a3568

Don't require ANDROID_BUILD_TOP to be set, and allow them to be used
in an `os.path.join` like manner.

Change-Id: I3fcae6341dcfe37b626d4df05a077c6d96a5fdca

Vim's make syntax highlighting doesn't understand that quotes in
$(error) directives aren't actually quoted strings.

Change-Id: I9fce6cdabc8ad8cabf806fb33b4dd67f63eba2f3

This is no longer needed since there are no
unwanted symbols in libc.so under
development/ndk/platforms/

Bug: http://b/26805673
Change-Id: I734271a3a08bf30428306d68b289ad79673c58d0

If we extract the modules to a known location we can reuse the
directory for testing. This cuts the final unpack out of our build ->
package -> unpack -> repack -> unpack -> test process.

Change-Id: I254c4dc4f13d70d881fe98cc418eb333ba1e6d7d