mk: make the dev kit configuration available while Android.mk is parsed - #7897
Open
andrew2311 wants to merge 2 commits into
Open
mk: make the dev kit configuration available while Android.mk is parsed#7897andrew2311 wants to merge 2 commits into
andrew2311 wants to merge 2 commits into
Conversation
added 2 commits
July 29, 2026 11:05
Add ta_dev_kit_conf, which exports conf.h, conf.mk and conf.cmake. They are written by plain shell commands, so this target compiles nothing and completes in about a second, unlike ta_dev_kit, which builds the libraries too. It is meant for dev kit consumers that need the configuration before they can build anything: optee_test picks its sources from the CFG_* flags it reads from the dev kit conf.mk, and some build systems have to know their sources before any rule can run. Signed-off-by: Andrii Shtompel <andrii_shtompel@epam.com>
Run ta_dev_kit_conf while the makefiles are parsed, so that the configuration is on disk before any Android.mk is read; building the dev kit itself is left to the graph as before. The md5 of the generated conf.mk is kept in a variable so that ckati parses again when the configuration changes, even though it comes from files ckati never reads itself. All optee_os invocations now share one command line, so the configuration read while parsing cannot drift from the one the dev kit is built with. This is for the Android.mk files which select what to build from the CFG_ flags of the dev kit, as optee_test does for its GP socket tests. They read them with -include $(TA_DEV_KIT_DIR)/host_include/conf.mk, which finds nothing on a clean build: ckati parses the makefiles to emit the ninja graph, and the dev kit is built by that very graph. The flags then come out empty and the sources they select are dropped with no diagnostic, so what ends up in the binary depends on whether the output directory is warm. No build dependency can fix this, as the parsing is what produces the rules. Signed-off-by: Andrii Shtompel <andrii_shtompel@epam.com>
|
FYI @taddk |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds
ta_dev_kit_conf, a target that exports the dev kit configuration(conf.h, conf.mk, conf.cmake): the files are written by shell commands, so
it builds no libraries and takes about a second.
mk/aosp_optee.mkthenruns it while the makefiles are parsed, so the configuration is on disk
before any
Android.mkis read. Building the dev kit itself is left to theninja graph, as before.
The md5 of the generated conf.mk is kept in a variable, so ckati re-parses
when the configuration changes, even though that configuration comes from
files ckati never reads itself. All optee_os invocations now share one
command line, so the configuration read while parsing cannot drift from the
one the dev kit is built with.
This fixes a long-standing trap for
Android.mkfiles that select what tobuild from the CFG_ flags of the TEE they are built against -
-include $(TA_DEV_KIT_DIR)/host_include/conf.mk, as optee_test does for itsGP socket tests. On a clean build that include finds nothing, because ckati
parses the makefiles to emit the ninja graph and the dev kit is built by
that very graph: the flags come out empty and the sources they select are
dropped with no diagnostic, so what ends up in the binary depends on whether
the output directory happens to be warm. It was reported as
OP-TEE/optee_test#275 in 2018 and closed without a fix; no build dependency
can close it, since the parsing is what produces the rules. The approach
here is the one @jforissier suggested in OP-TEE/optee_test#825, making the
dev kit configuration a required input.