In make, all product variables are assigned to an empty string before
including the product config makefiles. In starlark, we don't do that
just so the memory usage is smaller. This means that in make, using
?= to assign a product config variable has no effect. Replicate this
behavior in starlark by not emitting any code for ?= assignments of
product variables.
Fixes: 304324003
Test: go test
Change-Id: Id31531506ac9e372a1bea92ce9ae8e17ae0ca70c
It was 150, but an internal change bumped up the usage to 153. Temporarily increase it to fix build break.
Bug: b/284854738
Change-Id: I23478f4c5333c5ef1ad344aadafe5803685c5d92
Test: abtd
Test: treehugger
Previously, mk2rbc would output absolute paths in the load statements.
This caused issues with the new module resolution logic in rbcrun,
and is not something we'd want to check in anyways.
Bug: 280685526
Test: go test
Change-Id: Iae6e3f6be9cecc8e19b6e1fd33c5575ff6864654
Our boolean support is not fully fleshed out enough to make variables
real booleans. Keep them strings for now to resolve CI failures.
Bug: 275865081
Test: ./build/bazel/ci/rbc_dashboard.py --quick with aosp/2526609
Change-Id: I636bd9f39b50a47ecf92aecd2bf8ea41eac4d604
The standard go tooling assumes that a package's binary name should be
the name of the containing folder. Before this change, `go install` or
`go build` (without `-o`) names this binary `cmd`.
Test: treehugger
Change-Id: I45a4e97f4a0d59744d644e30636250ceefe3bd1c
Previously, when seeing a `include foo/$(VAR)/bar.mk`, the include
tops wouldn't apply to filter down the results any further.
Allowing include_tops is useful here to prevent cycles in the
load graph.
Fixes: 236025787
Test: go test
Change-Id: I3ea445f222ee2283a68d4aca5002df750204076f
In make, the result of $(foreach $(x),$(y),$(foreach $(z),(w),a))
is a regular list, but in Starlark it's a list of lists. Flatten
the results of foreach expressions where each element is a list
so that they're regular lists of strings again.
Bug: 226974242
Test: go test
Change-Id: I3210d409aba0d807a5890e341ab1e0c0478f5930
firstword/lastword need to be able to give an empty string when
the input is empty, which the indexing operator can't do.
Bug: 226974242
Test: go test
Change-Id: I44162a258297b32ec27e7acfb1fa06223391dcc6
Previously, if there was a cycle of load statements,
mk2rbc would exit with status code 1 but not give
any message indicating what went wrong.
Bug: 226974242
Test: Manually
Change-Id: I7d30cad08bd3abcd761b5f28a63a2cc66b45e805
Since the rbc results file is sorted, .KATI_READONLY
ends up trying to make a variable that hasn't been defined
yet readonly, which is an error.
It's not really worth supporting moving it down in the list,
because it wouldn't affect the variable being writable while
still in Starlark code.
Bug: 226974242
Test: go test
Change-Id: I9402f69be97e5c7cf010ad86f124422ea55fda7f
Previously, seeing anything other than an interpolate variable
was not allowed.
Bug: 226974242
Test: go test
Change-Id: I48a060f9a3fd19cd67a114d2cb0756ab2be25ce1
Some functions are called without the use of $(call),
since $(call) is not necessary when the function doesn't
take any arguments. mk2rbc thinks these function calls
are local variables, and converts them as such. This
leads to undefined variable errors when trying to load
(before even executing) the starlark file.
Hardcode a known function that should not be converted
to a local variable.
Bug: 226974242
Test: go test
Change-Id: I5567a34fcc282b181a7e78ac3d5cc9b40bd025a2
These private variables sometimes have references to make
variables like $< or $@. When converted to starlark, they
become invalid local variables like _< and _@, preventing
the file from being loaded even if it's never executed.
Bug: 226974242
Test: go test
Change-Id: Iafd4c6939731f3b7c051c9e41464134d5b672f23
Also remove the file existence functions because they
can just be wildcards instead.
Bug: 226974242
Test: go test
Change-Id: Icbf65c47af97a710580864e8b76e2697aba96dd8
These occur in some vendor makefiles in
order to include files in a foreach loop.
Bug: 226974242
Test: go test
Change-Id: I59242eba9a2d7c659994556d9123b6481f4a8130
This allows the parsing code to be cleaner, as it
doesn't have to care about variable assignments.
Bug: 228518745
Test: go test
Change-Id: I33425c2fb51acab4901bfa82a53d337b75210f8e
Include/inherit-product calls already allow asterisks, the
wildcard is not necessary. If we see an include using $(wildcard),
act as if it doesn't exist.
Bug: 218736658
Test: go test
Change-Id: Ib21007a2042fbfaa95c07571792983e14135a035
This is mostly so that we can not error out when
seeing sort inside a `include $(sort $(wildcard foo/*.mk))`.
Bug: 218736658
Test: go test
Change-Id: I827ecfc751a908227cb2dd9ed1e4b3f313791a16
While supporting $(eval) in the general case is
impossible, as it would require emitting code at
runtime, it is possible to handle some special cases
that are common throughout the code base.
Specifically, an assignement expression (where the
left hand side is constant) can be converted without
needing to evaluate strings as code, as its whole
right hand side is treated as one string.
However, this eval with an assignemnt can only be
used as a statement, not an expression. So it requires
the eval to be either a top-level expression, or nested
within other expressions that can be converted to
statements such as $(foreach) or $(if).
Bug: 226974242
Test: go test
Change-Id: Ifc52ef9ab7d62a69251918fcde5463f80a98a542
This is so that we can set LOCAL_PATH to the result
of my-dir, as LOCAL_PATH can only be set to a string
literal of the exact value of LOCAL_PATH.
It's probably also the correct choice to start phasing
out LOCAL_PATH.
Bug: 214405650
Test: go test
Change-Id: Ia97d7fedf4ce62643921d90a176e65edd4e2fce6
