Otherwise we'll re-run the primary builder every time this is used. This
triggered my new ninja checks that verify that all commands write their
outputs.
Change-Id: Ic92d1ea57203b953da8025a170b24e6420c5436c
* aosp/upstream:
WalkDeps - only record module visited when it has been recursed into
Allow missing variants when allowMissingDependencies=true
bpmodify: fix os.Exit() shouldn't shadow panic()
bpmodify: respect exitCode
Set bpmodify usage function
Test: treehugger
Change-Id: Ida99d7412ea3c034e1ddce228b1e851c1dc40cc2
Previously, WalkDeps() would record that a module was visited after the
first time it encountered the module irrespective of whether it recursed
into or not. This change moves the recording so it happens only after it
has been recursed into.
Added TestWalkDepsDuplicates_IgnoreFirstPath to test the change. Without
the change the test fails because it does not visit E.
Test refactoring:
* A depsMutator was added instead of relying on blueprintDepsMutator to
allow different tags to be used for different dependency types.
* Modified barModule and fooModule to support the new depsMutator and
add support for another type of dependency that is ignored by the
walking code.
* Extracted walkDependencyGraph() function to reuse common code.
The `defer func() { os.Exit() }()` in main() method shadows panic().
Make the exit handler recover() from panic(), log the panic(), and then
gracefully exit.
Test: m bpmodify
Change-Id: Icc89f8fce0b6096489baa0ba0f08c21d1ef623bc
golang `flag` package's default FlagSet `flag.CommandLine` calls
`flag.Usage` and `os.Exit(2)` on error to print the usage string.
Set `flag.Usage` to our custom usage function.
Test: m bpmodify; bpmodify -h; bpmodify --help
Change-Id: Ida107b0dbb07c291c3d7ea90eda9147d04a7cd51
Mutators were not propagating the results of ctx.AddNinjaFileDeps.
Test: examine out/soong/build.ninja.d
Fixes: 150689149
Change-Id: Ia1e69ebc9dfa94a05f4ecd9cc2a8691ee63c9dd5
* aosp/upstream:
Fix PropertyNameForField for X86.
Support unpacking capitalized property names
Make ninjaString an interface
Fixes: 148865218
Test: m checkbuild
Change-Id: I3680cd261bf420601a7b943e21acde6837ae8619
Field "X86" has no lowercase runes and was being left uppercase.
Change the new PropertyNameForField rules to lowercase the name unless
it has any uppercase rune after the first rune (which is always
uppercase) and no lowercase runes.
Bug: 148865218
Test: proptools_test.go
Change-Id: Ifd1c10fc03f5ae1765d25b3f73dba8fd61c5c956
Soong config variables may propagate an uppercase name from Make.
Blueprint properties have traditionally been all lowercase, and
using an uppercase property struct field name resulted in a strange
Blueprint property name with the first rune lowercase and the
remaining runes uppercase.
Update the rules for proptools.PropertyNameForField to not lowercase
the first rune if the field name has mulitple runes and is not all
uppercase.
Fixes: 148865218
Test: proptools_test.go
Change-Id: I8de2f65ffb00e5a8ce0aea0caf09f5859315f6b8
There are 8935901 *ninjaString objects generated in an AOSP
aosp_blueline-userdebug build, and 7865180 of those are a literal
string with no ninja variables.
Each of those *ninjaString objects takes a minimum of 48 bytes for
2 slices, plus 8 bytes for the pointer to the ninjaString. For
the literal string case, one of those slices has a single element,
(costing another 16 bytes for the backing array), and the other
slice is empty, for a total of 72 bytes.
Replace *ninjaString with a ninjaString interface. This increases
the size of the reference from 8 bytes to 16 bytes, but using
a type alias of a string for the literal string implementation uses
only 16 bytes, saving 40 bytes per literal string or 314 MB.
Test: ninja_strings_test
Change-Id: Ic5fe16ed1f2a244fe6a8ccdf762919634d825cbe
The proptools functions took an inconsistent variety of
struct and *struct types. Some methods even took a struct
but returned a *struct. Make all the exported methods
take a *struct, with internal helpers for the ones that need
to take a struct.
Test: proptools tests
Change-Id: I60ce212606e96adcef66c531d57f69c39e1a1638
Parser.parseVariable method should always set the value of the variable
it creates. Failure to do so may end up in the following:
```
$ androidmk <(printf "FOO:=(X)\nFOO:=bar\n")
parse error:
<input>:3:1: variable already set, previous assignment: FOO@<input>:1:5 = %!s(PANIC=String method: runtime error: invalid memory address or nil pointer dereference) (%!s(PANIC=String method: runtime error: invalid memory address or nil pointer dereference)) false
```
The cause is that calling Parser.Parse to parse `FOO=abc` created
a Variable instance with nil value, causing panic on print attempt.
Test: m androidmk && androidmk <(printf "FOO:=(X)\nFOO:=bar\n")
(should print:
ERROR: parse error:
<input>:3:1: variable already set, previous assignment: FOO@<input>:1:5 = X = Not Evaluated (X = Not Evaluated) false)
Change-Id: I296d7984df6d8796e0075f9eb692b234f8c94f08
* aosp/upstream:
Remove blueprint:"filter(*)" tag support
Make FilterPropertyStructSharded smarter
Bug: 146234651
Test: m checkbuild
Change-Id: Ib3de8d8dd43e6354c17f1734705a9feb2ca7f701
The filter tag is unused, replaced with FilterPropertyStruct to
generate a new type at runtime that only contains the filtered
fields.
Test: unpack_test.go
Change-Id: Id91cf99290832094d05426f3263279836f0fea73
FilterPropertyStructSharded was just sharding the top level
properties into groups of 10. For nested property structs
this can be insufficient - there could be a single top level
property with many properties below it.
Take a maximum name size, and track the size used by parent
structs to determine when sharding a nested struct is necessary.
Bug: 146234651
Test: filter_test.go
Change-Id: I5b5ed11ea27a0325b2fd6c2c3fb427ea1e2af0c2
