By default, nanopb outputs a timestamp into the .c and .h files it generates.
This is usually considered bening. However, when using remote execution or
remote caching, this poisons all actions that have these files as inputs, and
also appears to affect transitive actions (actions depending on actions that
have these files as inputs).
This change adds the -T flag to suppress the timestamp, which in turn makes
the output files deterministic, which in turn allows the remote cache to
return previous results rather than requiring a re-execution of the
corresponding actions.
Test: ran the build a few times to check that the output is deterministic
Change-Id: Iecfa143dbf12a9bb7703dd0bc3f1b3e3fd56317c
Native compiler flags are currently applied in approximately:
global cflags
local cflags
local include dirs
global include dirs
global conlyflags
local conlyflags
global cppflags
local cppflags
This means that a flag that is enabled in the global cppflags
cannot be disabled in the local cflags, and an Android.bp author
must know to disable it in the local cppflags. A better order
would be:
global cflags
global conlyflags
global cppflags
local cflags
local conlyflags
local cppflags
local include dirs
global include dirs
We are mixing both the global and local cflags into a single
variable, and similar for conlyflags and cppflags, which
prevents reordering them. This CL prepares to reorder them
by splitting the global and local cflags into separate variables.
Bug: 143713277
Test: m native
Change-Id: Ic55a8c3516c331dc5f2af9d00e59ceca9d3e6c15
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
When compiling nanopb static library, we need to add 16bit or 32bit
flag if we need to use 16bit or 32bit size, default is 8bit.
Change-Id: Ib74478996cb2487accc1e46a32fba8170214c47f
Test: None
Bug: b/122292884
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
ParseGeneratorParameter delimits based on commas, not colons:
external/protobuf/src/google/protobuf/compiler/code_generator.cc
Bug: 72570104
Test: flash device with new build
Change-Id: I00042782a718d288ca6b0cb78f856d0fb223a926
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
there's no use case for prepending/appending to bool, and string
properties within module struct. Declearing "*bool" and "*string" almost
cover everything user need.
I did see one case that user specify relative_install_path as
path prefix in cc_defaults, and concatenate with the one in real module
to get the final relative install path in Android.bp <bionic/tests/libs>.
Test: m -j checkbuild
Bug: b/68853585
Change-Id: If3a7a2689c3fc307aae136af6bc9c57f27a1e1a0
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
Descriptions currently look like:
[ 0% 4/29328] cc out-soong/.intermediates/external/clang/lib/Sema/libclangSema/android_arm_armv7-a-neon_denver_static_core/obj/external/clang/lib/Sema/SemaCodeComplete.o
This is not very helpful - most of the characters are used to show the
output path, which contains useful information like target architecture,
but also contains most of the path to the source files twice, and less
useful information like the exact variant name used by soong.
Make the descriptions look like:
[ 0% 3/29329] //external/clang/lib/Sema:libclangSema clang++ SemaTemplateInstantiate.cpp
This is //path/to/module:modulename tool relative/path/to/source/file
Test: builds, looks pretty
Change-Id: I3087aa7d4eb1860ef6239d77407b8b35445616d7
Allow properties to be overriden by arch variants.
Add include_dirs and local_include_dirs properties.
Pass -I . to fix:
frameworks/base/proto/src/metrics_constants.proto: File does not
reside within any path specified using --proto_path (or -I). You
must specify a --proto_path which encompasses this file. Note that
the proto_path must be an exact prefix of the .proto file names --
protoc is too dumb to figure out when two paths (e.g. absolute and
relative) are equivalent (it's harder than you think).
Test: m -j libplatformprotos
Change-Id: I3e02621ca25bfa7ca0a0e3b83377d70dd352668f
We were emulating this for proto files, standardize it and make the
other generators use it as well.
Test: Compare out/soong/build.ninja before/after change
Test: mmma -j system/tools/hidl
Change-Id: I1888c7b981749060a398387bbb9b481270bf6d75
.proto files are translated to .pb.cc and .pb.h files, which are then
compiled normally.
Bug: 32286026
Test: mmma -j system/extras/perfprofd
Change-Id: I538071424d667aacf35b4b8bfebe217f5f092726
