Repository navigation
xtensa-build-all: document PRIVATE_KEY_OPTION and deprecate -k - #3512
Conversation
|
@marc-hb, yes looks good. I wonder could we even add a concrete example like in some man pages, like: to build with docker for tgl with private/external key and meu tool: This would make it very clear how to do it. |
lgirdwood
left a comment
lgirdwood
left a comment
There was a problem hiding this comment.
looks good, could you add a litte more help for the user so they know the new switch/env variable to use in this case.
1e834e3 to
f2a3439
Compare
Following commit 88b69cc ("scripts: xtensa-build-all: Add support for building TGL and signing with MEU") we now have an unified and flexible PRIVATE_KEY_OPTION that can do anything with very little code. The -k option was never a good idea in the first place because it already required an environment variable anyway (RIMAGE_PRIVATE_KEY) instead of a command line argument so the code should have just checked whether RIMAGE_PRIVATE_KEY was defined, that would have been enough. Requiring the user to "double-confirm" with -k has been adding extra complication for both the user interface and the implementation. xtensa-build-all is effectively a "CMake configuration convenience" script, however it shouldn't become an additional layer of indirection and complexity and its interface should expose CMake (which is already a layer of indirection!) as directly as possible. See longer discussion in PR thesofproject#3187 Signed-off-by: Marc Herbert <marc.herbert@intel.com>
f2a3439 to
89cb96e
Compare
We don't have man pages, I think the closest is sof-docs. Happy to review anything you submit there :-)
I already added something very close to this in the I didn't add I didn't add |
Following commit 88b69cc ("scripts: xtensa-build-all: Add support
for building TGL and signing with MEU") we now have an unified and
flexible PRIVATE_KEY_OPTION that can do anything with very little code.
The -k option was never a good idea in the first place because it
already required an environment variable anyway (RIMAGE_PRIVATE_KEY)
instead of a command line argument so the code should have just checked
whether RIMAGE_PRIVATE_KEY was defined, that would have been
enough. Requiring the user to "double-confirm" with -k has been adding
extra complication for both the user interface and the implementation.
xtensa-build-all is effectively a "CMake configuration convenience"
script, however it shouldn't become an additional layer of indirection
and complexity and its interface should expose CMake (which is already a
layer of indirection!) as directly as possible.
See longer discussion in PR #3187
Signed-off-by: Marc Herbert marc.herbert@intel.com