Before this change, path of the install name is relative to the top dir.
That means you can execute dynamically-linked binaries only in the top dir.
With this change, you can execute dynamically-linked binaries anywhere.
Change-Id: I1c6441579ffb68505ea678296aceb2e66a6df1be
I got an Out of memory while compiling, Andreas Huber suggested that
increasing the heap size, which worked.
Change-Id: Id8293ef100ef814b0fe13aa6e1b891a36a2ee853
This replaces the list maintained in build/core/main.mk
by 2 makefiles in sdk.git and development.git.
Pre-requisite CLs: Change Ifa8111dbae for sdk.git
and Change Ie6f728bee for development.git
Change-Id: Id6178b000c464c989da2c7f22977986a60de1f44
What was I thinking?
That would be *ridiculous*.
What sane person would come up with a release like that?!?
I mean... four words! Six if you try to say it! Insane!!
Instead, we shall call you:
Jelly Bean.
Yum.
Change-Id: Ice28fc17b7eb77cf6b708958161339890234d1d8
Sometimes TARGET_TOOLS_PREFIX is passed in as command line makefile
variable or environmental variable without TARGET_TOOLCHAIN_ROOT.
This change computes TARGET_TOOLCHAIN_ROOT from TARGET_TOOLS_PREFIX in
that case.
Change-Id: I0a37dc1f4d1e3e1951faeffd5e9f926f0a6614dd
When this is enabled we ensure that files from the vendor directory
get installed to /system/vendor/* instead of elsewhere in /system/*.
This changes the PRODUCT_RESTRICT_VENDOR_FILES variable
to accept "owner", "path", "owner path", or "all".
"true" will still only enforce vendor file owner restrictions.
Change-Id: I4598130a590ad56976e011f4cb2a9f5f227d5732
So we can have the same set of module names in different host arch
/ toolchain version combinations.
Change-Id: Iec66584bf3de92aedd71a59f9dbe74b6ed025b2e
Only generate the core test and vmtest descriptions when something has
actually changed rather than everytime CTS is built. This should make
iterative test development in CTS more pleasant.
The rule targets are changed to be the paths of the test description
XML files in a separate directory outside of the CTS distribution.
The buildCts.py rule copies these XMLs when they change to the
final CTS distribution location and creates the final plan file.
The dependencies have also been changed to reply upon the full
package paths rather than their phony targets to avoid rebuilding
everything all the time.
Finally, the AppSecurity rule was removed, because I have taken
care of that in my prior change to the Makefiles in the CTS
project.
Change-Id: I88b92c7a4cb4c2c2e20f06641e7ba0604d37f805
With this change, if a module name is associated with multiple modules,
you can specify multiple install paths in
PRODUCT_FACTORY_RAMDISK_MODULES.
For example, if we have 2 modules named "foo", one is Java library and
the other is executable, then you can write:
PRODUCT_FACTORY_RAMDISK_MODULES += \
foo:system/bin/foo:system/framework/foo.jar
Or:
PRODUCT_FACTORY_RAMDISK_MODULES += \
foo:system/bin/foo \
foo:system/framework/foo.jar
The build system will choose the correct built files based on the
install paths.
Change-Id: I6efc72e8abd1e81710ada16731b6792989aefd85
OTOH, should we just allow the expression to be >= 3.81
for all platforms? For cygwin it's a specific case since
we don't build the platform, only a handful set of tools
and it works just fine with a newer make 3.82.
Change-Id: Icff0d0e13bce79f7164007985f14db56e9049552
