Currently, both stdout and stderr are redirected to a file. We want
stderr to be visible on the terminal in case the release config
fails.
Test: m nothing
Change-Id: I1337718fe8f9394be3017cc8b6d76f8dc1a94ef0
This reverts commit 3f0eba2bdc.
Reason for revert: Causes build flag changes to be ignored sometimes. Better fix is in progress.
Merged-In: Ic85be1da3765656cef8da4ec03d0b1ca7d5d625e
Change-Id: I2c06770b2ff86c69a5de89962ab9bf48bedfe6fe
If RELEASE_BUILD_FLAGS_IN_PROTOBUF is False, then the results from
out/release-config are ignored and we do the old processing.
The following additional logic all goes away once the migration to protobuf
is finished.
- If we found .textproto files that don't have corresponding .mk files,
we require protobuf.
- If we found .mk files that don't have corresponding .textproto files,
we require legacy (make) processing.
- If PRODUCT_RELEASE_CONFIG_MAPS specifies .textproto files, we require
protobuf.
In order to further isolate migration, the choice can be determined on a
release-config by release-config basis. in each release config
directory, we look for:
- `build_config/DEFAULT=proto`
- `build_config/DEFAULT=make`
- `build_config/${TARGET_RELEASE}=proto`
- `build_config/${TARGET_RELEASE}=make`
The last such file found determines which code path is used.
Bug: 328495189
Test: manual, TH
Change-Id: I1d84db76b157082fc7db1b3cb7c9afe8cdf46cbf
Only include a release_config_map.mk file the first time it appears in
the list.
If the flag declaration is identical to one already declared, do not
raise an error.
This eases the process of migrating where flags are declared.
Bug: b/328781415
Bug: b/328495189
Test: manual, TH
Change-Id: I18316e769438f62071723771762d6e89be98b813
Merged-In: I18316e769438f62071723771762d6e89be98b813
This should be used to declare that a release config is an alias for
another one. Aliases have no release config files of their own, and are
primarily used to simplify continuous integration as releases happen.
Bug: None
Test: manual
Change-Id: Ife5eb1f8f4bf8e06832dc55bbc390ce2f741ebb8
When overriding a release config, make sure that the overriden config is
fully present (by processing any of its overrides) before overriding it.
Bug: None
Test: manual
Change-Id: I8d29c7ee7208acf7fe63876f617c5b9e2c26c434
A release config declaration may indiciate that one or more other
release configs should be applied before this one overrides them, so
that we don't have to manually keep common flags in sync.
Bug: b/313479515
Test: manual
Merged-In: Ib7350500ae44adf4767aa7f9dbb8e71609fdd8c0
Merged-In: Ida444a5dbba578a36bd3607246fa14fc73b3f923
Change-Id: Ida444a5dbba578a36bd3607246fa14fc73b3f923
Relanding because we've fixed a number of the broken build
setups this change exposed. We will push to fix forward broken
build setups instead of reverting this change again.
Rather than use an unsupported flag setting that the user likely
doesn't even realize is being used, we immediately stop the build.
This error message is more verbose, mentioning 'lunch', because
it's anticipated a lot more users will hit this issue when first
switching to trunk stable, and more details will hopefully help
them out.
We have some complication in that some internal commands set
TARGET_RELEASE to an empty string. We put in logic to allow
that path.
Since $(error) immediately stops the build, we also get rid of
some 'else' logic and indentation, to hopefully offset some of
the complication we've added.
Bug: 307946156
Change-Id: I0fa4a1c876e607401f4c7f945b9971cfb8db71a0
Test: 'lunch' (still) works; A build attempt without `TARGET_RELEASE` set (now) fails
Rather than use an unsupported flag setting that the user likely
doesn't even realize is being used, we immediately stop the build.
This error message is more verbose, mentioning 'lunch', because
it's anticipated a lot more users will hit this issue when first
switching to trunk stable, and more details will hopefully help
them out.
We have some complication in that some internal commands set
TARGET_RELEASE to an empty string. We put in logic to allow
that path.
Since $(error) immediately stops the build, we also get rid of
some 'else' logic and indentation, to hopefully offset some of
the complication we've added.
Bug: 307946156
Test: 'lunch' (still) works; A build attempt without `TARGET_RELEASE` set (now) fails
Change-Id: I2f667668c6688e501a3536981b7bae5fdbf962a0
These files don't have anything to do with bazel, they just use starlark as a configuration
language. Bazel recently introduced the scl file extension to use for this format, which doesn't
have any bazel-specific symbols. Use that extension for our pure starlark files as well.
Bug: 309686282
Test: Presubmits
Change-Id: I7b08f342e7fb94405a52af0918ae6a7d542f3282
1. release config maps now specify where the flag definitions are found.
2. PRODUCT_RELEASE_CONFIG_MAPS specifies additional release config map
files to use.
This allows product config to specify build flags, which can then be
specified by users of that product.
Bug: b/302593603, b/309477343
Test: manual
Change-Id: Ic1f0512ec4b06ac94dd3f29eadd6a03ba8ebf6d2
1. release config maps now specify where the flag definitions are found.
2. PRODUCT_RELEASE_CONFIG_MAPS specifies additional release config map
files to use.
This allows product config to specify build flags, which can then be
specified by users of that product.
This reverts commit 75bfc37ef4.
Bug: b/302593603
Test: manual
Change-Id: I031a00459893644d7f67b63b982db9ae9015ae4d
Revert submission 2787001-product-build-flags
Reason for revert: Possible cause of b/308849337
Reverted changes: /q/submissionid:2787001-product-build-flags
Bug: 302593603
Bug: 308849337
Change-Id: I01b5905a0a20a1401dcc1267e7fafc893e57d637
1. release config maps now specify where the flag definitions are found.
2. PRODUCT_RELEASE_CONFIG_MAPS specifies additional release config map
files to use.
This allows product config to specify build flags, which can then be
specified by users of that product.
Bug: b/302593603
Test: manual
Change-Id: I660a3d88c2aaecc14d6f370bebb0d05a8cc224f2
The "next" targets aren't supported yet, so we want to fail
immediately.
If the environment variable TESTING_TARGET_RELEASE_NEXT is
set, then we'll allow a "next" build, so folks can work on
fixing this in the meantime.
Bug: 294161396
Test: "lunch mokey-next-userdebug" with and without TESTING_TARGET_RELEASE_NEXT set
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:f40be02ee51dec1bd5cdf88a4419684585ef6ef3)
Change-Id: If478a4efef937a0a986bfefdb61cc25921863b25
Bug: 285303012
Test: for x in next trunk trunk_food trunk_staging ; do lunch aosp_panther-$x-eng ; m nothing ; done
Change-Id: I174ce3e609fa9077ea6bc61679ddb83e8efe57c8
For now (to prevent build breakages when this is submitted), duplicate
flag values are allowed, but that will be disallowed once this change
automerges everywhere.
Bug: 286689485
Test: Treehugger
Change-Id: I723340ff9751b61d33c4108b0cc2f90702a116c9
Also gets the json summaries working again.
Bug: 283477392
Test: Manual
Merged-In: Iaeb840e96bd7fef2fa1492cb55d9688f7ca75858
Change-Id: I05d9b816ad7ad30c1d238d01df811426d9aeddcb
So that we have a more restricted enviornment for this new configuration
axis that can also be imported into other tools more easily.
Test: Manually (this time also tested setting OUT_DIR outside of the tree)
Change-Id: I01d90e06e45cba756156af16f63e04f575877263
This reverts commit c113a70221.
Doesn't work with OUT_DIR hard coded outside the tree.
Test: OUT_DIR=/source/whatever m
Bug: 283278495
Change-Id: I8cc74a9ec936b9c7502b97b9b7a4fd731988c407
So that we have a more restricted enviornment for this new configuration
axis that can also be imported into other tools more easily.
Test: Manually
Change-Id: Iabce1919f6d6f57a256ae144784af7c47622b54d
