llext-edk: minor fix, add board info

[pillo79]

• Fix the EDK handling of -imacros to also include the case where no space is found between the flag and the file path.
• Use the entries for cmake board name, cmake board qualifiers, and cmake board revision in the build_info.yml file to export this information to EDK files along with a sanitized board target.
• Add documentation for the new exported variables.

[teburd]

@edersondisouza you should likely take maintainership of EDK related things, I don't know all the ins and outs of it.

[tejlmand]

does this work with --imacros=<file> ?

That construct is allowed by clang and other compilers based upon clang.

[tejlmand]

technically you're not creating the board target here, because a board target has the form:

https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#board-terminology

Please use another variable name to avoid confusing readers in the future who looks at this code.

[tejlmand]

it seems to me that zephyr_build_string() is a better choice so that any changes or extensions to board terminology is automatically picked up. (SiP could be a future example).

zephyr/cmake/modules/extensions.cmake

Lines 1590 to 1657 in 895d911

	# Function to create a build string based on BOARD, BOARD_REVISION, and BUILD
	# type.
	#
	# This is a common function to ensure that build strings are always created
	# in a uniform way.
	# A single string is returned containing the full build string constructed from
	# all arguments.
	#
	# When MERGE is supplied a list of build strings will be returned with the full
	# build string as first item in the list.
	# The full order of build strings returned in the list will be:
	# - Normalized board target build string, this includes qualifiers and revision
	# - Build string with board variants removed in addition
	# - Build string with cpuset removed in addition
	# - Build string with soc removed in addition
	#
	# If REVISION is supplied or obtained as system wide setting a build string
	# with the sanitized revision string will be added in addition to the
	# non-revisioned entry for each entry.
	#
	# Usage:
	# zephyr_build_string(<out-variable>
	# BOARD <board>
	# [SHORT <out-variable>]
	# [BOARD_QUALIFIERS <qualifiers>]
	# [BOARD_REVISION <revision>]
	# [MERGE [REVERSE]]
	# )
	# zephyr_build_string(<out-variable>
	# BOARD_QUALIFIERS <qualifiers>
	# [MERGE [REVERSE]]
	# )
	#
	# <out-variable>: Output variable where the build string will be returned.
	# SHORT <out-variable>: Output variable where the shortened build string will be returned.
	# BOARD <board>: Board name to use when creating the build string.
	# BOARD_REVISION <revision>: Board revision to use when creating the build string.
	# MERGE: Return a list of build strings instead of a single build string.
	# REVERSE: Reverse the list before returning it.
	#
	# Examples
	# calling
	# zephyr_build_string(build_string BOARD alpha)
	# will return the string `alpha` in `build_string` parameter.
	#
	# calling
	# zephyr_build_string(build_string BOARD alpha BOARD_REVISION 1.0.0)
	# will return the string `alpha_1_0_0` in `build_string` parameter.
	#
	# calling
	# zephyr_build_string(build_string BOARD alpha BOARD_QUALIFIERS /soc/bar)
	# will return the string `alpha_soc_bar` in `build_string` parameter.
	#
	# calling
	# zephyr_build_string(build_string BOARD alpha BOARD_REVISION 1.0.0 BOARD_QUALIFIERS /soc/bar MERGE)
	# will return a list of the following strings
	# `alpha_soc_bar_1_0_0;alpha_soc_bar` in `build_string` parameter.
	#
	# calling
	# zephyr_build_string(build_string SHORT short_build_string BOARD alpha BOARD_REVISION 1.0.0 BOARD_QUALIFIERS /soc/bar MERGE)
	# will return two lists of the following strings
	# `alpha_soc_bar_1_0_0;alpha_soc_bar` in `build_string` parameter.
	# `alpha_bar_1_0_0;alpha_bar` in `short_build_string` parameter.
	#
	# calling
	# zephyr_build_string(build_string BOARD_QUALIFIERS /soc/bar/foo)
	# will return the string `soc_bar_foo` in `build_string` parameter.
	#

[pillo79]

@tejlmand thanks for the insights! Issues have been addressed, please re-review.

[tejlmand]

lgtm, although there is a potential risk of a very rare edge-case if using -imacros=foo.h. (single dash variant).

But as I don't expect anyone to be using filenames with = as first char, then I'll leave it for you to decide if you want to adjust code.

[tejlmand]

just want to mention that -imacros= != --imacros=.

The single dash version doesn't support a = as arg-val separator, meanining -imacros=foo.h will include the file =foo.h, but --imacros=foo.h will include foo.h.

So:
-imacrosfoo.h == --imacrosfoo.h == --imacros=foo.h

and
-imacros=foo.h == --imacros==foo.h == --imacros =foo.h (note the space)

I don't expect anyone to create or generate header files having = as first character but still wanted to mention this slight difference between -imacros and --imacros.

[pillo79]

I knew the catch-all regexp would match extra combinations, but... is it valid to have relative paths among the zephyr_interface flags anyway? I intutively expect that to cause build issues (outside of the EDK).

Anyways, I personally prefer the simplicity; if that becomes an issue we can switch to a more formal definition.