Group protoc calls to generate java files into groups of 100
to avoid having a srcjar for every proto file.
Test: m checkbuild
Change-Id: I72a5efaabad24c975282df321d00ec2d7900645e
Treat proto.type: "javanano" as a plugin by explicitly passing the
path to protoc-gen-javanano. This allows removing the javanano
customizations from the core plugin code, which no longer supports
javanano natively.
Bug: 117607748
Test: m checkbuild
Change-Id: Id7ed92d45583a7930f35c6734605d9304704bdbc
Merged-In: Id7ed92d45583a7930f35c6734605d9304704bdbc
Treat proto.type: "javamicro" as a plugin by explicitly passing the
path to protoc-gen-javamicro. This allows removing the javamicro
customizations from the core plugin code.
Bug: 117607748
Test: m checkbuild
Change-Id: I703a8c1b788d77dcf6c656e79cab1c02171aa94e
Replace the common pattern of:
cmd.Tool(ctx.Config().HostToolPath(ctx, "tool"))
with:
cmd.BuiltTool("tool")
And similarly for PrebuiltBuildTool.
Test: m checkbuild
Change-Id: I7d63188505362c7df6a3b3e7330b4a2cca5a2409
Add a proto.plugin property to allow specifying a custom protoc
plugin to generate the code.
Fixes: 70706119
Test: m am StreamingProtoTest
Change-Id: I1ecdd346284b42bbcc8297019d98d2cd564eb94c
Using blueprint.Rule for protoc commands was causing code duplication
because there was no good way to run the same protoc for cc, java and
python but then run custom source packaging steps for java and python.
Move most of the code into a common function that returns a
RuleBuilder, and then let java and python add their own commands at
the end of the rule.
Bug: 70706119
Test: All Soong tests
Test: m checkbuild
Change-Id: Ic692136775d273bcc4f4de99620ab4878667c83a
Protobuf 3.5.2 does not natively support lite protos, instead they
are generated by the protoc-gen-javalite plugin compiled from
external/protobuf-javalite.
Bug: 117607748
Test: m checkbuild
Change-Id: I95c2d873f19d4c00e9dc312d7fdbe98cae250a8b
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
protoc dependency files, at least for C++ outputs, uses the form of:
a/b.c \
a/b.h: <dep1> <dep2>...
Ninja will fail the command when it parses a dep file and there's more
than one output file (even though it doesn't care what the output file
name is). So this tool will parse the original file, and output a
version with only a single output file.
Bug: 67329638
Test: NINJA_ARGS="-t deps ...pb.c" m
Test: NINJA_ARGS="-t deps ...srcjar" m
Test: NINJA_ARGS="-t deps ...srcszip" m
Test: Run dep_fixer across all of taimen's dep files, no failures.
Test: Run dep_fixer against the processed files, no changes.
Test: Run androidmk across all of our Android.mk files, inspect the diffs
Change-Id: I4263b7d5faea37285afa6b24dedf5964aa7d19dc
Historically, we've always passed '-I .' as the first argument to
protoc, essentially treating all proto file package names as their full
path in the android source tree. This would make sense in a monorepo
world, but it makes less sense when we're pulling in external projects
with established package names.
So keep the same default (for now), but allow individual builds to opt
into using local paths as the default names with
'canonical_path_from_root: false'. A cleanup effort and/or large scale
change in the future could change the default to false.
As part of this, run protoc once per input proto file, since the flags
may need to change per-file. We'll also need this in order to specify
--dependency_out in the future.
Bug: 70704330
Test: aosp/master build-aosp_arm.ninja is identical
Test: aosp/master soong/build.ninja has expected changes
Test: m
Test: Build protobuf test
Change-Id: I9d6de9fd630326bbcced1c62a4a7e9546429b0ce
Allow java modules using proto to specify output params to be
passed to the proto generator.
Test: m checkbuild
Change-Id: I8a06f07218073236f4f85996ea5f09fb3702ed1a
javastream proto is rarely used and tricky to support directly
in java because it depends on an extra host tool. It can be
supported with a genrule, so just remove the partial built-in
support.
Test: m checkbuild
Change-Id: Iffe75e7040cb889ca17fdd85ef3e8e64fc3aa9e9
Compute the common proto flags and pass them to the protoc invocation
when generating java files.
Test: m checkbuild
Change-Id: I0d4c23ad001d01eab03b404545383f009214106d
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
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
Colin Cross