[RFC] llext-edk: capture full build properties for EDK export

[pillo79]

Not for merge in 4.3, obviously - at this stage, looking for feedback on the approach and especially if others had similar issues with the EDK.

The symptom

While developing the Arduino core, we encountered an issue compiling code that used the fatfs module via the EDK; it looked like some defaults were being used in the extension, even though specific compile options were applied during the main Zephyr build.

The actual problem

Tracking down the source revealed that the EDK is not exporting all build information, but only those defined by the Zephyr core (the zephyr_interface target). Modules do not interfere with the Zephyr core but insert themselves as dependencies of the app target, so transitive evaluation applies there only.

Ruled-out solutions

• The current way of reading properties (e.g. zephyr_get_compile_options_for_lang) cannot be used for the app target, because at the time the main Zephyr CMakeLists.txt is evaluated, that target is not yet available (and definitely not fully configured).

• Trying to use generator expressions is also not possible, due to CMake not allowing expansion of $<COMPILE_LANGUAGE:...> outside of a proper compile context. These expressions were stripped by complex code in get_*_for_lang functions, but that's no longer possible if the actual flags are hidden in a genex. The process errors out at configuration time.

The proposed solution

To work around this, this change introduces a new CMake subdirectory (misc/llext_edk) that creates a dummy target which imports the build configuration from app, but overrides the C compile rules to simply output the resulting properties (defines, include directories, flags) to text files. The EDK generation script then reads those text files to get the full set of build properties, and includes them in the EDK tarball.

Important

This (ab-)uses the CMake build process in a way that is often cited as an error - setting toolchain variables from a CMakeLists.txt selectively overrides an existing configuration, and is typically discouraged. However, that's 1) documented, stable behavior and 2) exactly what we are after in this case: use every option from the existing toolchain, but "discard" the compiler executable.

A test has been added to verify the functionality by checking if a symbol defined in an interface library that is a dependency of app is properly exported to the extension.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[edersondisouza]

Interesting hack! Two questions:

1- I noticed that there seems to be less duplication of flags - like, less times the drivers include dir appears on the flags after your changes - is this expected? Why did we have some many duplicates anyway?
2 - Where is this documented as a stable behaviour? Would it make sense to have a link to that for future reference?

[edersondisouza]

After this, llext_filter_zephyr_flags isn't used anymore, right? Couldn't it be removed then?

[teburd]

Ederson is the author of the EDK and I've reassigned it to match this