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
Currently, a string variable can easily be reassigned to
a different type. Make it so that the value it's being
reassigned to is converted to a string first.
Bug: 224601891
Test: go test
Change-Id: I82252cf9e106b5a3677458cf1df2e9d1dfefe0f6
Type hints have the format #RBC# type_hint MY_VAR list
and must be specified at the top of the Makefile. Setting
one will cause that variable to have that type for the
remainder of the Makefile. This can be used where mk2rbc's
type inference detects the wrong type and it must be
manually changed.
Bug: 224601891
Test: go test
Change-Id: I6db2c50056d0298227e1d2801a522adf8bbd1df8
- Remove asgnMaybeAppend, it was only used to indicate
that the asignment needs a setDefault. But really, all
types of variable assignments need setDefault if they're
self-referential.
- Remove local_append/local_set_default because there was
no implementation for them written in product_config.rbc
anyways.
- Correct productConfigVariable.emitDefined using the global
variables instead of the product config variables.
- Emit setDefaults for all types of assignments if they're
self referential.
Bug: 222737841
Test: go test
Change-Id: I06a0f90f16d5900049d473281e6d5ef5e93e67da
In aosp/1962181 an "optimization" was added where if an include
path with a variable only matches one file, that file would be
called directly instead of going through the whole _entry
variable.
This doesn't work when there is an inherit-product-if-exists call
that matches one file, but that file isn't the one that is specified
at runtime. In reality, the inherit-product-if-exists call should
see that the file doesn't exist and not include anything.
Fixes: 222341691
Test: go test
Change-Id: If8789de0013726137683078355161eecdec009b1
This is so that:
- It's consistent with product configuration
- The return type of board/product config's main functions
and the arguments to printvars can be changed without
also making a change in the soong repository. (what I'm about
to do)
- Removes obsolete TODO
Bug: 221312856
Test: Presubmits
Change-Id: I593f180881eab9521012df202af8f0233bc0b6ae
This commit doesn't attempt to replace the filter
calls with anything more idomatic for now.
It also removes the case for filter-out, because
the actual function name is filter_out and wasn't
being used anyways. Even if I were to change it
to filter_out, that would produce buggy results:
ifneq (,$(filter $(TARGET_BUILD_VARIANT), userdebug eng))
endif
ifneq (,$(filter-out $(TARGET_BUILD_VARIANT), userdebug eng))
endif
Both of these would produce:
if g["TARGET_BUILD_VARIANT"] in ["userdebug", "eng"]:
pass
Fixes: 218702402
Test: go test
Change-Id: I566079e5d3a364c42db14045aa1bab9d99eba05f
This allows us to use relative paths everywhere.
It also produces more accurate emulation of TOPDIR,
which should be an empty string.
Bug: 213508006
Test: go test
Change-Id: Ie4e357687486e84e9f4aad0f6776d8feb2b9fc63
Having soong generate a list of makefiles for mk2rbc
to look through is much faster than having mk2rbc search
itself. Profiling the readLinesFromeFile() function that
reads the list of makefiles shows it takes on the order
of 200 microseconds, much faster than the ~5 seconds
it takes for mk2rbc to search the tree itself.
This CL also allows include statements that are prefixed
with a variable. The concern with this was that there
would be a lot of load statemnts emitted for generic
include statements, causing the generated code to look
ugly, and converting and loading all those files could
cause performance issues. On the performance issues
front, there's already a check that it doesn't result
in over 150 potentially included files. We can lower
that number if necessary, but it's probably good for now.
On the generated code front, while it's true that it's
ugly, it's better to have working but ugly generated
code than refusing to generate anything working at all.
To ensure the soong finder step isn't slowed down due
to having to find a bunch of new makefiles, I profiled
the combination of newSourceFinder and FindSources in main.go:
Baseline incremental:
338.011634ms
340.853335ms
348.541762ms
333.229644ms
349.124824ms
Baseline clean:
1.003836419s
1.006203912s
996.193648ms
1.031005604s
1.03691152s
Modified incremental:
349.029285ms
349.264496ms
351.774948ms
337.63187ms
359.425306ms
Modified clean:
1.028238704s
1.053103506s
1.032757506s
1.016631201s
1.04288108s
So we can see the times are barely affected by this change.
Fixes: 213508006
Test: go test
Change-Id: Iab18bfb127ba3b7e63f2c01f69064805a8398764
Currently, mk2rbc is structured around having a global
"receiver" object that accepts all starlarkNodes. As soon
as they are parsed they are added to the receiver.
Returning the parsed nodes to the calling function is more
flexible, as it allows the calling function to restructure
them as necessary. This is the first step to supporting
complicated statements involving $(eval), such as
`$(foreach v,$(MY_LIST),$(eval MY_LIST_2 += $(v)))`
Test: go test
Change-Id: Ia194123cf090d2b9559a25b975ccbc5749357cc0
mk2rbc was already searching the whole android tree
for Makefiles, so allowing variable-prefixed include
statements doesn't affect performance on the file searching
front. On the generated code front, there's already a cap
of 150 potentially-included makefiles that prevents the
performance from getting too bad, and it can be lowered
if necessary.
Bug: 213508006
Test: go test
Change-Id: I3a4e81acb3d97bee08ac3dbe63052a274acf5793
The module name passed to rbld.inherit should be its path without the suffix.
Bug: 215182113
Test: internal
Change-Id: Ic65a5b73037be84f31f8db29f71f793b6c6034bb
VariableDefinedExpr was under-developed, and would not
take into account if a variable was from the globals
or product config dictionary.
It also always emitted `g.get("VARIABLE") != None`, which
is not correct behavior. In this example makefile:
```
MY_VAR :=
ifdef MY_VAR
$(info MY_VAR is defined)
else
$(info MY_VAR is not defined)
endif
ifdef MY_UNDEFINED_VAR
$(info MY_UNDEFINED_VAR is defined)
else
$(info MY_UNDEFINED_VAR is not defined)
endif
MY_VAR ?= true
MY_UNDEFINED_VAR ?= true
$(info MY_VAR after ?= is $(MY_VAR))
$(info MY_UNDEFINED_VAR after ?= is $(MY_UNDEFINED_VAR))
.PHONY: all
all:
@:
```
We get the output:
MY_VAR is not defined
MY_UNDEFINED_VAR is not defined
MY_VAR after ?= is
MY_UNDEFINED_VAR after ?= is true
So we can see that even if a variable was set, it's considered
not defined if it was set to an empty value. However, ?= works
differently, and does require the != None, so that was left
as is.
Just use a variableRefExpr and rely on the fact
that variables will be truthy if they're defined.
Fixes: 216700361
Test: go test
Change-Id: If8944da2579e8658e3fc4f666b1f3b2815f8c8b1
A potentially inherited (via dynamically calculated path) module may in turn
unconditionally load a module that does no exist in a source tree -- it is
not an error if this potentially inherited module is actually never inherited
because its dynamically calculated path will never reference it. Instead of
emitting an uncoditional `load` for a non-existent file (which is going to fail
in the Starlark parser), emit conditional load and a runtime check.
Fixes: 213922819
Test: internal
Change-Id: I92177878e199a1f00e5f0c4045c0c0daeddd6bdb
mk2rbc implements conversions for both
is-board-platform(-in-list) and
is-board-platform(-in-list)2. The conversions
are not the same despite the functions being the
same. Make them convert to the same thing.
Bug: 201477826
Test: go test
Change-Id: I688a2f6114e1688c713e42f0f9229cbc5ee6a917
Previously adding an include_top comment would make it apply
for the rest of the file. This was confusing behavior, and
could also cause extra roots to be searched in a situation
like the following:
\#RBC# include_top foo
include $(VAR)/file.mk
\#RBC# include_top bar
include $(VAR)/file.mk
Here the second include would have file.mk from both the foo
and bar directories in its _entry dictionary.
Bug: 213508006
Test: go test
Change-Id: If3430594759bee1390255400fe29b43d77f7b6a6
Converts the following functions from build/make/common/math.mk:
- math_max
- math_min
- math_gt_or_eq
- math_gt
- math_lt
Fixes: 213497955
Test: go test
Change-Id: I8c4e8fee321f03b813428fa10038fa8f06188cef
By having knownFunctions contain parsing interfaces
instead of just metadata about the function, we can
remove some hardcoded special cases.
Bug: 201700692
Test: go test
Change-Id: I1723c7f50b72d42b03380e999aa9601b455a969e
The include_tops hints are global for the whole parse
context (which is probably also something to fix), which
means that if an include_top hint is duplicated there will
be duplicated keys generated in the _entry starlark dictionary.
Bug: 193566316
Test: go test
Change-Id: I01a0546ac9be91ef46c5248e87e1a40e0f211193
It was only used to substitute variable references to
predefined variables with the predefined value, which
is an easy condition to directly parse into instead
of having a separate evalutation pass.
Bug: 201700692
Test: go test
Change-Id: I543d20a1d6435bfabd9faa90ffb09af3084ed28c
