buildDef.WriteTo was calling valueList to convert all the build
parameter ninjaStrings into strings, which uses ValueWithEscaper
to build a strings.Builder. This results in building a string
only to immediately copy it into the output writer's buffer.
Instead, pass an io.StringWriter to ValueWithEscaper so it can
build the string directly into the output writer's buffer. This
requires converting ninjaWriterWithWrap into an io.StringWriter.
Test: ninja_writer_test.go
Change-Id: I02e1cf8259306267b9d2d0ebe8c81e13dd443725
Arguments to build definitions were copied from the input map to an
map with the name and value expanded, then to a list of names for
sorting, and then written, which required iterating over a map three
times. Expand the name and value into a list of name value pairs,
and then do the rest of the operations on the list instead.
Test: ninja_writer_test.go
Change-Id: Id8ff644dafbaa3b4812747c60dc28cce22e21dbe
The Android fork of Ninja supports "validations", a node that is
added to the top level of the build graph whenever another node
is in the build graph. Add support in Blueprint to specify them
on build statements and write them to the ninja.
Test: ninja_writer_test.go
Change-Id: I87cd1281dbd2ed113cc26a265c50d20c65118c91
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
Writing the ninja file to a byte buffer causes a significant amount
of time to be spent in memmove when growing the byte slice. Write
the file directly to disk instead.
This also fixes some unhandled error warnings, which become more
likely when doing disk IO instead of byte buffer writes.
Change-Id: I5094e4c45cab4012713037f60c5a4fb00718f92e
Commands that contain tools that don't affect the build results
may want an order-only dependency on the tool. Allow rules
to specify order-only dependencies the same way they specify
implicit dependencies.
Test: builds
Change-Id: I3e0f886ae047b0fadf7a5c0dfeb9827d2c5c411d
Ninja supports deps and depfile properties specified on build
statements, allow them to be specified in BuildParams.
Change-Id: I46eac5571350426f1419908def21f7d042f8739a
Turn PackageContext into an interface so that build systems can wrap it
to add more custom helpers.
This does introduce an API change, though it should be fairly simple.
NewPackageContext used to provide an opaque *PackageContext struct, now it
provides a PackageContext interface.
Change-Id: I383c64a303d857ef5e0dec86ad77f791ba4c9639
For implicit dependencies that will be common to all users of a Rule,
add a new field 'CommandDeps' to the RuleParam. This is a list of
strings to be prepended to the implicit dependencies in each BuildParam.
This lets us have the dependencies declared next to where they are used,
instead of duplicated in areas that may be far apart.
I looked at passing this information down to ninja too, but it only
saves us a few percent of ninja file, and requires a modification to the
ninja file format.
Change-Id: Ifd910dee1506d4e32a76ed06206f853c4caec622
Make integrating with go tools easier by putting the blueprint package
files in the top level directory of the git project instead of in a
subdirectory called blueprint.
Change-Id: I35c144c5fe7ddf34e478d0c47c50b2f6c92c2a03
