Replaces the BottomUpMutatorContext parameter with a new
SdkDependencyContext type that extends BottomUpMutatorContext. This is
to allow the sdk to pass additional information to the implementations
of that method to allow the behavior to be more finely tuned.
Bug: 195754365
Test: m nothing
Change-Id: I69c6d2c523934eb67d7a7e6c55c241e9b8a81773
Previously, only those SdkMemberTypes which had specific need to
automatically add some of their dependencies as sdk members would cause
the sdk to visit their transitive dependencies. However, as any module
can have dependencies on license modules and license modules need to be
included in the sdk then it needs to visit transitive dependencies of
all members.
So, this change removes the support for allowing an SdkMemberType to
control whether its transitive dependencies are visited and just visits
them all.
This does not have any effect on sdk snapshots as in order for a
dependency to be added to an sdk it needs to be added with a tag that
implements SdkMemberTypeDependencyTag and the only tags that implement
this are used by SdkMemberTypes that had enabled transitive members.
Bug: 181569894
Test: m art-module-sdk art-module-host-exports art-module-test-exports
- verify that this change has no effect on the generated snapshots
Change-Id: If0293af0237aa7e39335e5b8383a41c023ff5853
A follow up change will add methods to SdkBase which requires its
module field to have been initialized.
Bug: 181569894
Test: m nothing
Change-Id: I9b02f260ad3f82316cc7ab3b5717b7e81090b0d8
Previously, every module added to an sdk directly through one of the
SdkMemberType specific properties, e.g. java_libs, was exported and
every module added automatically via a transitive dependencies was not
exported. This change allows that behavior to be customized per tag.
Bug: 186290299
Test: m art-module-sdk
- verify that this change does not affect its contents.
Change-Id: I563b5bcd823e61c23cdb706cfcbb13337963d550
Make sure that java_system_modules_import always depends on the
prebuilt by adding dependencies in the ComponentDepsMutator() method
which is called before prebuilts without a corresponding source are
renamed from prebuilt_<x> to <x>. That requires the prebuilt_ prefix
to be provided but it ensures that the dependencies are safe.
Similar logic also makes sure java_system_modules always depends on
the source module and not on a renamed prebuilt module.
Bug: 182402568
Test: m nothing
Change-Id: I30db95978f5d9b205951011edf40585ee36c0c4c
Export information about java dependencies through a Provider
instead of accessing the module directly.
Test: java_test.go
Test: no changes to build.ninja
Change-Id: Ifc5d566bf6f6ebc0ad399e948effaa1ef6a22876
Revert submission 1377717-metalics
Reason for revert: This has broken renderscript_mac target for aosp-master, see b/176909442
Reverted Changes:
I26ac54ca9:Define the standard license_kind rules.
I656486070:Export soong license data to make.
If9d661dfc:Export soong license data to make.
I97943de53:Add ability to declare licenses in soong.
Icaff40171:Rough-in license metadata support to make.
Ib8e538bd0:Add variables for notice deps, license kinds etc.
Change-Id: I51799c94a274eadab414abd80a07b5cda4584be9
Migrates system modules and droid stubs over to use the new API for
creating the snapshot modules and removes the old API.
Test: m nothing
Change-Id: Ia825767f1f7ee77f68cfe00f53e09e6f6bfa027f
This change ensures that the runtime dependencies between a
binary/shared library are correctly specified in the snapshot so that
the build can ensure that shared libraries are built before the targets
that use them.
It adds support for differentiating between references that are
required to refer to another sdk member (required) and those that may
refer to either an sdk member or a non-sdk member (optional). The
latter is used for shared library references as the libraries used by
an sdk member may be provided from outside the sdk. e.g. liblog is not
part of the ART module but is used by some members of the ART sdk.
Bug: 142935992
Test: m nothing
Change-Id: Ia8509ffe79b208c23beba1880fe9c8a92b732685
Previously, there were some places where a java_system_module_import
could not be used in place of a java_system_module. That was because
the code assumed a *SystemModules type not a *systemModulesImport type.
This change introduces a SystemModulesProvider interface that is used
instead and is implemented on both types.
Bug: 142940300
Test: m nothing
ran new tests before changes to make sure they detected the issue
and after to make sure the changes fixed the issue.
Change-Id: I7b16ac5708880bdf61e6f5b1e6616c986f0ed763
Adds an SdkMemberType implementation for java_system_modules. It
specifies that java_system_modules can be used with sdk as well as
module_exports, and also that the libs property should be included
as transitive members in the sdk.
It also adds support for treating appropriate tagged properties in
the snapshot prebuilts module as references to sdk members so that
they are correctly transformed when creating the versioned modules.
Bug: 142940300
Test: m nothing
Change-Id: Ic10b5a6d5b92b6018334fe876f06feaf79cc55e9
A prebuilt version of java_system_modules. It does not import the
generated system module, it generates the system module from imported
java libraries in the same way that java_system_modules does. It just
acts as a prebuilt, i.e. can have the same base name as another module
type and the one to use is selected at runtime.
Bug: 142940300
Test: m nothing
Change-Id: I126db49d18294fcd6e2b7ad0237f83e9c2fdef7a
With this change, setting the environment variable
EXPERIMENTAL_USE_OPENJDK11_TOOLCHAIN=true switches from the OpenJDK 9
toolchain to the OpenJDK 11 one (prebuilts/jdk/jdk11).
Since the version of the java.base module has to match the version of
the jlink tool which consumes it, the --module-version argument to the
jmod create call is also switched.
Test: make
Test: EXPERIMENTAL_USE_OPENJDK11_TOOLCHAIN make
Bug: 131683177
Change-Id: I606d22538165f309fe5537bd67a26390b1dd5771
This rule takes a moduleName parameter which only ever has the value
java.base. What's more, the assuption that the value will always be
java.base is baked into the rule in other ways (most significantly,
the module created with this name is passed to jlink, and jlink
requires a java.base module).
This change removes the parameter and hard-codes java.base everywhere,
on the basis that it's better to have it completely hard-coded than
partially configurable and partially hard-coded.
Test: make
Change-Id: Ib42cda92f623c5a1f929b5a99248ca8919e4700c
Adds a library dependency to each of the dummy system modules created
by testing.go so that any changes in the behavior were detected by
the existing tests which were then fixed.
Bug: 141359858
Test: m checkbuild
Change-Id: Id4442f4aa3931ac93049f3367b96a5b49cc075e1
This was preventing us from actually using system module dependencies
from Make.
Fixes: 135679136
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true m legacy-performance-test-hostdex
Change-Id: Ic51c30d09cf39e35f2fe5f534a23273f450d9138
This jlink plugin is intended to optimise startup times for Java
runtimes by embedding a pre-processed and pre-validated module graph
in the system image.
This provides no benefit on Android, since the Android runtime does
not make use of the module graph it produces. (It doesn't seem useful
on Android anyway, since the system image only contains one module,
namely java.base.)
Furthermore, the plugin causes the jlink invocation to fail when using
the jlink tool from OpenJDK 11. The issue here is the plugin uses
classes in the jdk.internal.module package to describe the module
graph; that package is not part of libcore and therefore not listed in
the module-info.java for java.base on Android; but the plugin has the
side-effect of adding the package to java.base; this causes jlink to
subsequently fail with an error "Module java.base's descriptor
indicates the set of packages is : <lots of packages>, but module
contains packages: <same packages plus jdk.internal.module>". (The
implementation of the plugin changed significantly in OpenJDK 10,
which is presumably why this issue does not occur using OpenJDK 9's
jlink.)
Therefore, it is safe and beneficial to disable the plugin.
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true make core-all-system-modules, using an OpenJDK 11 toolchain via OVERRIDE_ANDROID_JAVA_HOME and changing the jmod create invocation to use --module-version 11
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true make droid, flash to device & sanity check
Bug: 131683177
Change-Id: I52333f32c88aa85cd3652ad91d50d9927ff61daf
ctx.AddDependency will succeed if the named dependency only has a
single variant, even if that variant is the wrong architecture.
Use ctx.AddVariationDependency(nil, ...) instead, which requires
that all variations of the calling module match the dependency.
Bug: 112707915
Test: no change to out/soong/build.ninja
Test: using a device dependency in a host java module is an error
Change-Id: I70b661a57d4412eb63b8c9841febfb756e9e025d
The flag EXPERIMENTAL_USE_OPENJDK9 controls the *default* value
of java_version / LOCAL_JAVA_LANGUAGE_VERSION, but that default
value can be overridden by individual build targets.
One requirement for individual build targets to opt-in to
java_version 1.9 is for system modules to be generated even if
the default language version is still < 1.9. We plan to allow
this soon for libcore targets; therefore, this CL changes the
system module targets to always be defined, regardless of the
value of EXPERIMENTAL_USE_OPENJDK9.
Test: In a workspace that has http://r.android.com/646840
"make" no longer runs into the build failure from bug 76219552.
Bug: 76219552
Change-Id: I5193347452c7967f7695929619509aea0fd46844
Add a method on ModuleContext and TopDownMutatorContext to visit
direct dependencies that have a given dependency tag.
Test: m checkbuild
Change-Id: Ib875563091dcae6b7282b3e3427d0eb07d8c8af5
AConfig() now duplicates Config(). Replace the uses of AConfig()
with Config(). Leave AConfig() for now until code in other
projects is cleaned up.
Test: m checkbuild
Change-Id: Ic88be643049d21dba45dbd1a65588ed94bf43bdc
OpenJDK9 system modules are not build modules, which means they
can't be built with m core-system-modules. Add a phony target.
Test: m core-system-modules
Change-Id: If6d512ff7a009b49743fb25cbb566935ec1c0153
Also adds checks that the dependencies are android.Modules and
are not disabled.
Test: m checkbuild
Change-Id: I05e945f38915d49cd3c0ab72a86576949bc7eff2
Now that android.ModuleContext does not include blueprint.ModuleContext
we can rename android.ModuleContext.ModuleBuild to
android.ModuleContext.Build without colliding with
blueprint.ModuleContext.Build. Leave ModuleBuild as a wrapper around
Build for now to avoid having to update all the users outside
build/soong simultaneously.
Test: m checkbuild
Change-Id: I18eb8cc04faf002049a11d9aac97e9732ff5d638
If sdk jars(android_stubs_current, etc) are compiled using soong java
modules, we have to filter them when running Java build with Turbine.
TODO: provide more unit-tests.
Test: m clean && m -j32; go test java_test
Change-Id: Iad7c241b0e8b0ca760950733f513124b56c84564
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
