Until now only generated assembly or C++ files would be compiled. This patch extends the build
system to compile generated C files as well. The new rule is modeled on the existing rules for
compiling generated C++ files and the existing rule for compiling ordinary C files.
* changes:
Change 77 from git master branch: change the prelink-linux-arm.map to include OC 2.0 new shared libs - remove redundant share lib from the map - remove 2way share lib from the map
Merge commit '7b2845ab1a47324a6fb25261048510e79656a732'
* commit '7b2845ab1a47324a6fb25261048510e79656a732':
Don't rebuild the NOTICE files when building with mm, mmm, etc.
Merge commit 'e468abda1c64923908ae711743d3e8c9f1b4a477'
* commit 'e468abda1c64923908ae711743d3e8c9f1b4a477':
AI 147775: Also add ApiDemos to make sure it gets included in the TestCase repository as
Merge commit 'ecc08d02b18f67a84df2f69e0d807761fc8dad15'
* commit 'ecc08d02b18f67a84df2f69e0d807761fc8dad15':
AI 147731: Forgot to submit the build changes for the
Merge commit '41ddfa903fe4e91e51d978d30bbbe6748ed1f100'
* commit '41ddfa903fe4e91e51d978d30bbbe6748ed1f100':
AI 147479: Update list of CTS test packages.
Merge commit 'ccd2def288d02ce5adab10bb28878fff05b70aed' into donut
* commit 'ccd2def288d02ce5adab10bb28878fff05b70aed':
AI 147847: CTS: Fix core test dependencies in CTS makefile
Merge commit 'f22b9a0ad531f66eb0b5710abae1feefecc42c2b' into donut
* commit 'f22b9a0ad531f66eb0b5710abae1feefecc42c2b':
AI 147775: Also add ApiDemos to make sure it gets included in the TestCase repository as
Merge commit 'b3e0126a7a2d32fbae2638e9419739d2d3907c40' into donut
* commit 'b3e0126a7a2d32fbae2638e9419739d2d3907c40':
AI 147731: Forgot to submit the build changes for the
Merge commit 'f23f5b486650a923e58e3e79b8ec23cc725b7b33' into donut
* commit 'f23f5b486650a923e58e3e79b8ec23cc725b7b33':
AI 147479: Update list of CTS test packages.
The core test descriptions did not list all dependencies. When building cts
for the first time, the descriptions were generated before the cts
repository was erased.
BUG=1813815
Automated import of CL 147847
apks. Each libcore module gets one apk and luni gets 4.
Original author: ursg
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 146827
This is only a preliminary CL. More will follow but this is
a good start, with the following caveats:
What it does:
- take an input jar, a list of includes, a list of excludes.
- generate actual Java source for the filtered classes.
What it doesn't do yet:
- some more work on filtering inner elements (methods, etc.)
- properly generate inner classes.
- hide synthetic fields.
- some classes body are missing
- directly generate a stubbed bytecode/jar rather than source.
I'll likely want to keep the source generator for debugging
purposes or if we want to integrate with a build system instead.
- classpath will be changed in the final CL to refer to the external
ASM lib rather than the project. I need the source for debugging
rigth now.
- will review comments before submitting.
Original author: raphael
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 146498
This is only a preliminary CL. More will follow but this is
a good start, with the following caveats:
What it does:
- take an input jar, a list of includes, a list of excludes.
- generate actual Java source for the filtered classes.
What it doesn't do yet:
- some more work on filtering inner elements (methods, etc.)
- properly generate inner classes.
- hide synthetic fields.
- some classes body are missing
- directly generate a stubbed bytecode/jar rather than source.
I'll likely want to keep the source generator for debugging
purposes or if we want to integrate with a build system instead.
- classpath will be changed in the final CL to refer to the external
ASM lib rather than the project. I need the source for debugging
rigth now.
- will review comments before submitting.
Original author: raphael
Merged from: //branches/cupcake/...
Automated import of CL 145983
- rename the directory and zip file
- make it build to the dist directory
Original author: joeo
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 146003
This is only a preliminary CL. More will follow but this is
a good start, with the following caveats:
What it does:
- take an input jar, a list of includes, a list of excludes.
- generate actual Java source for the filtered classes.
What it doesn't do yet:
- some more work on filtering inner elements (methods, etc.)
- properly generate inner classes.
- hide synthetic fields.
- some classes body are missing
- directly generate a stubbed bytecode/jar rather than source.
I'll likely want to keep the source generator for debugging
purposes or if we want to integrate with a build system instead.
- classpath will be changed in the final CL to refer to the external
ASM lib rather than the project. I need the source for debugging
rigth now.
- will review comments before submitting.
BUG=1778786
Automated import of CL 145911
Use a different name for prebuilt libraries based on their LOCAL_MODULE --
they were all colliding using the same name, javalib.jar. These names
are synthetic, since the libraries don't actually exist on the device
as such.
- rename the directory and zip file
- make it build to the dist directory
Original author: joeo
Merged from: //branches/cupcake/...
Automated import of CL 145850
because the commandline is too long
Original author: joeo
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 145659
Original change by joeo@abreu on 2009/04/06 19:54:13.
Implement SDK add-ons in the build system.
- Add an option to use the standard javadoc doclet instead
of droiddoc, since droiddocs non-sdk templates aren't
ready for prime time.
- Add the notion of a stubs for a library. It's only
implemented for java libraries, but when we do native
libraries in the NDK or sdk-addons, it will work there too.
Original author: joeo
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 145655
Original change by joeo@abreu on 2009/04/06 19:54:13.
Implement SDK add-ons in the build system.
- Add an option to use the standard javadoc doclet instead
of droiddoc, since droiddocs non-sdk templates aren't
ready for prime time.
- Add the notion of a stubs for a library. It's only
implemented for java libraries, but when we do native
libraries in the NDK or sdk-addons, it will work there too.
Original author: joeo
Merged from: //branches/cupcake/...
Automated import of CL 145618
Original change by joeo@abreu on 2009/04/06 19:54:13.
Implement SDK add-ons in the build system.
- Add an option to use the standard javadoc doclet instead
of droiddoc, since droiddocs non-sdk templates aren't
ready for prime time.
- Add the notion of a stubs for a library. It's only
implemented for java libraries, but when we do native
libraries in the NDK or sdk-addons, it will work there too.
Automated import of CL 145333
* changes:
Ensure that /system/etc/vold.conf is created in the "generic" product. This is necessary to let the emulator mount SD Card images properly through the "vold" mounting daemon
them from an external file in the recovery image. Use the
test-keys for all builds.
Original author: dougz
Merged from: //branches/donutburger/...
Automated import of CL 144132
Fixes http://b.android.com/2308
This is not meant to be a permanent fix, but since everyone except
a handful of people need this, it's easier to set it for everyone
and have that handful of people unset is locally than to force
everyone to make a local tweak.
Fixes http://b.android.com/2308
This is not meant to be a permanent fix, but since everyone except
a handful of people need this, it's easier to set it for everyone
and have that handful of people unset is locally than to force
everyone to make a local tweak.
armv4 was only implemented on StrongArm and Arm8 (See http://en.wikipedia.org/wiki/ARM_architecture)
and will be more difficult to support since it does not support the bx instruction.
armv4t on the other hand is used in a wide range of cpu:s.
armv4 is also not supported by bionic or dalvik, but armv4t is.
Thumb-mode is not yet enabled since there are some unresolved abi-issues.
architecture versions other than ARMv5TE.
The general approach is to provide TARGET_ARCH_VERSION, to complement
TARGET_ARCH. This defaults to the current armv5te. The variable
values should match the architectures as defined by gcc.
There is a block of defines for each supported architecture version
(currently ARMv5TE and ARMv4). Each block defines a set of features
using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c
preprocessor defines to pass to the compiler. Finally it defines a
default CPU. (As for architecture versions, the default CPU should
match a CPU that gcc knows about.)
Support is added for architectures that do not support THUMB. Specifically
we change the 'thumb compile' target to simply compile as ARM code
instead, and we change the interworking flag passed to the compiler.
Finally, we ensure that the system/core/include/arch/linux-arm directory
is added to the default include path, which allows the use of asm/macros.h
header file described in review #1626. The way in which this done is
considerably unclean/hacky, if someone can suggest a better way please
let me know.
Note the hyphens in the error message are required because the output of
this scripts is used directly in a Makefile target.
Signed-off-by: Rod Whitby <rod@whitby.id.au>
