target.vendor.exclude_static_libs: this is the static counterpart of
target.vendor.exclude_shared_libs. This removes the libs from the static
dependency when build the vendor variant.
target.vendor.version_script: vendor-specific version script.
Right now, these are required to merge libseliux_vendor into libselinux
and make it vendor_avaialble:true. libselinux is using libpackageparser
which is a platform-only library. The vendor variant of libselinux can't
depend on the library.
Bug: 66914194
Test: lunch aosp_arm64_ab-userdebug; m libselinux.vendor
Change-Id: I163e634f2f54d419f9471a585a3b04731b63f809
This may happen if there's been another call to microfactory before
we've read the log file. Just ignore the error and continue.
Test: Run `while true; do get_build_var TARGET_PRODUCT; done` in parallel
Change-Id: I670144f4637281ebf1299dbd9151dd9819c363e3
Create a lock file during log rotation so that multiple processes won't
step on each other.
Test: Run `while true; do get_build_var TARGET_PRODUCT; done` in parallel
Test: m blueprint_tools
Change-Id: I7144cd42aca47c694487ddae44713f82665ed81e
This uses knowledge of transitive dependencies to reorder
linker command line arguments such that if module A depends
on module B, then module A is automatically listed before
module B in the linker command line.
This should mostly remove the need for Android.bp files to
list all of their static dependencies in link order
Bug: 66260943
Test: reorder the entries of static_libs in an Android.bp and see that linking still succeeds
Change-Id: I20f851ab9f2f30031254e4f30023b6140d15d6c3
Leave '__unix' and '__unix__' defined on mips/mips64, like arm.
This is needed to avoid a warning in external/libcxx project.
Test: successful build and boot aosp_mips-eng
Test: successful build and boot aosp_mips64-eng
Change-Id: I8f0e17bdbeffd5078c19aa7506564b8e79a9c945
javac warns whenever -source is used with a version that does not
match javac, because it wants an rt.jar provided for the given
source level. We are not using -source to prevent usage of APIs
that don't exist in the newer rt.jar, so hide the messages.
Test: javac_wrapper_test.go
Change-Id: Ic94b61767436848fc164e377dc3cc5a63726f1cf
Modules may need to use jarjar on the device to move classes into
the android namespace, but not on the host.
Test: m checkbuild
Change-Id: I910ebbe20e45e98edecca0d7c4fb18e806bc3c6c
Allow java libraries to specify .kt sources, precompile them with
kotlin, and then pass them in the classpath to javac.
Bug: 65219535
Test: java_test.go
Change-Id: Ife22b6ef82ced9ec26a9e5392b2dadacbb16546f
build/soong/soong_ui.bash --dumpvars-mode \
--vars="..." \
--abs-vars="..." \
--var-prefix="..." \
--abs-var-prefix="..."
is similar to the previous:
CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \
make -f build/core/config.mk dump-many-vars \
DUMP_MANY_VARS="..." \
DUMP_MANY_ABS_VARS="..." \
DUMP_VAR_PREFIX="..." \
DUMP_ABS_VAR_PREFIX="..."
and
build/soong/soong_ui.bash --dumpvar-mode [--abs] VAR
is similar to the previous:
CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \
make -f build/core/config.mk dumpvar-[abs-]-VAR
But uses soong_ui and ckati, so that we use a consistent make parser and
sandboxing configurations.
One major output difference between the pure make implementation and
this one is that report_config in Go is implemented using embedded
newlines in single quotes, while the make implementation uses `` with
embedded echo commands. This seems to work fine for both bash and zsh,
and report_config isn't meant to be machine-parsed anyways.
Test: build/soong/soong_ui.bash --dumpvar-mode report_config
Test: build/soong/soong_ui.bash --dumpvar-mode TARGET_DEVICE
Test: build/soong/soong_ui.bash --dumpvar-mode --abs PRODUCT_OUT
Test: build/soong/soong_ui.bash --dumpvar-mode --abs ALL_PRODUCTS
Test: build/soong/soong_ui.bash --dumpvars-mode --vars="report_config TARGET_DEVICE" --abs-vars="ALL_PRODUCTS"
Test: build/soong/soong_ui.bash --dumpvars-mode --vars=TARGET_DEVICE --abs-vars=PRODUCT_OUT --var-prefix=v_ --abs-var-prefix=a_
Change-Id: I0fbd0732bbf6fcfcd24084cf3c830a91a4b6bfc2
srcFileLists was an ill-fated attempt to deal with generators that
produce a set of java sources that is not known ahead of time.
For example, the list of files produced by protoc depends on the
package statement in the .proto file. srcFileLists put the list
of generated files into a file, which was then passed to javac
using the @file syntax. This worked, but it was too easy to cause
missing dependencies, and will not work well in a future distributed
build environment.
Switch to putting generated sources into a jar, and then pass them
jar to javac using -sourcepath.
Test: m checkbuild
Change-Id: Iaab7a588a6c1239f7bf46e4f1b102b3ef517619b
Pass the output file name into the java.Transform* functions.
This consistently puts control of the filename into java.go,
which is often necessary to avoid collisions when the same
rule is used multiple times in a single module. It also
has the side-effect of removing the poorly named "stem"
parameters.
Test: java_test.go
Change-Id: I7bc1d1f3bfae6f9d2c92870e6df381817817aab4
Adds a java_system_modules module type that (when
EXPERIMENTAL_USE_OPENJDK9 is set to true) converts a list of
java library modules and prebuilt jars into system modules,
and plumbs the system modules through to the javac command
line.
Also exports the location of the system modules to make
variables, as well as the name of the default system module.
Test: TestClasspath in java_test.go, runs automatically as part of the build
Bug: 63986449
Change-Id: I27bd5d2010092422a27b69c91568e49010e02f40
