Commit graph

8 commits

Author SHA1 Message Date
Yifan Hong
1b3348d50a Add ramdisk image.
It is similar to recovery image.
Test: m nothing -j

Change-Id: I11389777c6bfb0c0d73bbb4c70091c1e70f44077
2020-01-22 16:54:18 -08:00
Justin Yun
5f7f7e8a39 Create product variant for product partition
When PRODUCT_PRODUCT_VNDK_VERSION is set to 'current', product
modules are enforced to use only VNDK libs from the system partition
as BOARD_VNDK_VERSION does to vendor partition.

Modules with 'vendor_available: true' create product variant as well
as core and vendor variants. The product variant as an image variant
is used for the modules in /product or /system/product.

It must not affect the current build behavior without
PRODUCT_PRODUCT_VNDK_VERSION set.

Bug: 134099726
Bug: 138966004
Bug: 144534640
Test: build without PRODUCT_PRODUCT_VNDK_VERSION set
Change-Id: I4d3585c110d84493e45bf76d550dc240bb26137f
2019-12-20 17:56:08 +09:00
Colin Cross
fb0c16e95a Move imageMutator before archMutator
Run the imageMutator between osMutator and archMutator so that
different arch variants can be set for the different partitions.

Bug: 142286466
Test: m checkbuild
Change-Id: I65d05714b75aa462bf9816da60fdc2deda4de593
Merged-In: I65d05714b75aa462bf9816da60fdc2deda4de593
(cherry picked from commit 9c8f687584)
2019-12-17 14:45:11 -08:00
Colin Cross
7228ecd5e3 Move cc.imageMutator into the android package
Prepare for making the image mutator available to all modules and
moving it between the os and arch mutators by moving it into the
android package and using an interface implemented by the module
types to control it.

Bug: 142286466
Test: No unexpected changes to out/soong/build.ninja
Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
2019-11-20 15:21:32 -08:00
Jiyong Park
fc752ca1ac Let genrule be mutatable by the apex mutator
genrule modules were not mutated by the apex mutator. As a result, a
module that is mutated for an apex have depended on the genrule modules
host_bionic_linker_{asm|flags} that are not mutated for the APEX.

This in turn caused an inconsistency problem because the
host_bionic_linker_* genrules use the dynamic linker that isn't mutated
for APEX as an input, while the outputs of the genrules are used by
modules mutated for APEX. The inconsistency caused b/135008828.

Fixing this issue by correctly let genrule to be mutated by the apex
mutator.

Bug: 135008828
Test: checkout master-art-host
ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist
./art/tools/dist_linux_bionic.sh -j50 showcommands
com.android.runtime.host
is passing

Change-Id: I92d90400c61d3951f6202d932832d0cb63c95a7d
2019-06-12 13:28:11 +09:00
Jiyong Park
7ed9de3b81 Add support for versioned stubs.
A cc_library or cc_library_shared can be configured to have stubs
variants of the lib.

cc_library_shared {
    name: "libfoo",
    srcs: ["foo.cpp"],
    stubs: {
        symbol_file: "foo.map.txt",
        versions: ["1", "2", "3"],
    },
}

then, stubs variants of libfoo for version 1, 2, and 3 are created
from foo.map.txt. Each version has the symbols from the map file where
each symbol is annotated with the version that the symbol was introduced
via the 'introduced=<ver>' syntax. The versions don't need to be in sync
with the platform versions (e.g., P for 28). The versions are local to
the library.

For another library or executable to use the versioned stubs lib, use
the new 'name#ver' syntax to specify the version:

cc_binary {
    name: "test",
    ....
    shared_libs: ["libFoo#2"],
}

Internally, a new mutator 'version' is applied to all cc.Module objects.
By default, a variant named 'impl' is created for the non-stub version.
If the versions property is set, additional variations are created per a
version with the mutable property BuildStubs set as true, which lets the
compiler and the linker to build a stubs lib from the symbol file
instead from the source files.

This feature will be used to enforce stable interfaces among APEXs. When
a lib foo in an APEX is depending on a lib bar in another APEX, then bar
should have stable interface (in C lang) and foo should be depending on
one of the stubs libs of bar. Only libraries in the same APEX as foo can
link against non-stub version of it.

Bug: 112672359
Test: m (cc_test added)

Change-Id: I2488be0b9d7b7b8d7761234dc1c9c0e3add8601c
2018-10-30 09:55:48 +09:00
Jiyong Park
3f736c9661 Add recovery_available to cc_genrule
recovery_available property is required in cc_genrule. Specifically,
we will mark libminijail as recovery_available:true as part of building
adbd and other stuffs for recovery. Some source code of libminijail is
created via cc_genrule, so we need recovery_available in the module
type.

Bug: 79146551
Test: m -j
Change-Id: I0cf0d9b1004dda055373573e5c5a7debd112685f
2018-05-24 14:01:54 +09:00
Dan Willemsen
3e5bdf29ba Add cc_genrule
cc_genrule is the same as a normal genrule, but can depend on other cc
modules (like cc_object).

Test: mmma external/minijail
Change-Id: I8df87665c7bdc76ce89c92755c054f967a818e57
2017-09-18 23:33:25 -07:00