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
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
Spaces normally don't need to be escaped, but leading spaces are
trimmed. Escape leading space to allow setting a variable to a
value with leading spaces.
Test: ninja_string_test.go
Change-Id: Ic0ffb076dbd603b7c0203720b9c1ea635c5ded75
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
Naively pre-allocate ninjaString slices by counting $ characters as
an estimate of how many variables will be needed. Saves 5% cpu time
on one workload.
Change-Id: Ib3a41df559d728b2db047f6dbbf9eb06d7045303
If a $ sign occurs after a variable name, the ninja string parser
fails to check if it is a $$ or a ${. Go to the
parseDollarStartState instead of the parseDollarState.
Since it is not yet known if the $ is the beginning of a new
variable (${ or $<alphanumeric>) or a string ($$), an empty string
separator cannot be added to the ninjaString strings list. Instead,
add functions to push strings or variables onto the ninjaString,
and automatically add the blank separator if two variables are
pushed in a row.
Change-Id: Ia1cae6259b1d7e4f633f61b9eadb2a2028bbd5f0
Forcing module names to be valid ninja names is an unnecessary
restraint on the project build logic. Allow any string as a
module name, and sanitize and uniquify the module name for use
in module-scoped variables.
Also move the module scope to be per-module instead of per-group
so that modules can use the same local variable name for each variant.
Change-Id: If44cca20712305e2c0b6d6b39daa5eace335c148
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
2015-01-23 14:23:27 -08:00
Renamed from blueprint/ninja_strings.go (Browse further)
