The java module currently supports full, lite, micro, and nano protobuf
types, but it doesn't support the stream type. This commit fixes that.
Bug: 217241348
Test: go test ./java -run TestProto
Change-Id: Ifae51734103d424892b66da43ca51e7b6fbe45ba
`m platformprotos` with a long OUT_DIR can trigger E2BIG errors in
posixspawn, reduce the commands per shard.
Test: OUT_DIR=$PWD/really-long-out-directory m platformprotos
Change-Id: Ifa4594eac7ba0e1091df0ef75e4dfc3ff366939b
This currently expands all globs, still need to support converting glob
syntax.
Test: go build_conversion_test
Test: GENERATE_BAZEL_FILES=true m nothing
Test: m nothing
Bug: 165114590
Change-Id: If7b26e8e663d17566fad9614ca87a8da1f095284
IntelliJ's indexer is unhappy with the full paths in the proto
and aidl srcjars. Use the -srcjar argument to soong_zip, which
causes it to extract the correct filename for .java files based on
the package statement in the file.
Bug: 176209347
Test: manual
Change-Id: I63d9d4f6ba670e3b851835d719519d675ae54c7f
Enable the RuleBuilder and RuleBuilderCommand methods to access
the BuilderContext by passing it to NewRuleBuilder instead of
RuleBuilder.Build.
Test: genrule_test.go
Test: rule_builder_test.go
Test: m checkbuild
Change-Id: I63e6597e19167393876dc2259d6f521363b7dabc
Soong was incorrectly defaulting to compiling for full protos but
using the lite runtime. Switch to compiling lite protos by default.
Fixes: 119714316
Test: m checkbuild
Change-Id: I0832b854f01f2acb10682e68ce7cc68753ca9dda
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
