tests/pkg_utensor: model in Kconfig + fix utensor package dependencies

[aabadie]

Contribution description

This PR adds a Kconfig configuration to the tests/pkg_utensor application. The Kconfig dependency list had to be fixed and extended for this to work.

Note that this PR will fail on Murdock when build for esp32-heltec-lora32-v2. There's a module resolution mismatch with and without TEST_KCONFIG and I couldn't figure out the cause. It seems that libstdcpp dependencies are not resolved the same, adding ztimer deps without TEST_KCONFIG.

Testing procedure

Green Murdock

Issues/PRs references

None

[MrKevinWeiss]

I will try to take a look at the mismatch issue

[aabadie]

I will try to take a look at the mismatch issue

Thanks! (and good luck 🤞 )

[MrKevinWeiss]

You can try

diff --git a/sys/posix/pthread/Kconfig b/sys/posix/pthread/Kconfig
index 38f384d15f..9d88e957ab 100644
--- a/sys/posix/pthread/Kconfig
+++ b/sys/posix/pthread/Kconfig
@@ -8,3 +8,7 @@
 config MODULE_PTHREAD
     bool "Pthread Support"
     depends on TEST_KCONFIG
+    select MODULE_ZTIMER
+    select ZTIMER64_USEC
+    select MODULE_ZTIMER64_XTIMER_COMPAT if MODULE_ZTIMER_XTIMER_COMPAT
+    select MODULE_TIMEX

It looks like pthread needs ztimer stuff, cppstdlib needs pthread (only on esps), utensor needs cppstdlib...

[aabadie]

You can try

It doesn't seem to be enough (even if already better!):

$ BOARD=esp32-heltec-lora32-v2 make -C tests/pkg_utensor clean info-modules --no-print-directory > /tmp/make-modules && TEST_KCONFIG=1 BOARD=esp32-heltec-lora32-v2 make -C tests/pkg_utensor clean info-modules --no-print-directory > /tmp/kconfig-modules && diff /tmp/make-modules /tmp/kconfig-modules 
1,3c1,3
< rm -rf /work/riot/RIOT/tests/pkg_utensor/bin/esp32-heltec-lora32-v2/pkg-build/esp32_sdk
< rm -rf /work/riot/RIOT/tests/pkg_utensor/bin/esp32-heltec-lora32-v2/pkg-build/esp32_sdk_libs
< rm -rf /work/riot/RIOT/tests/pkg_utensor/bin/esp32-heltec-lora32-v2/pkg-build/utensor
---
> === [ATTENTION] Testing Kconfig dependency modelling ===
> === [ATTENTION] Testing Kconfig dependency modelling ===
> make: Nothing to be done for 'clean'.
7d6
< auto_init_ztimer64
57d55
< periph_init_timer
63d60
< periph_timer
83,84d79
< ztimer64
< ztimer64_init
92d86
< ztimer_periph_timer

Another Kconfig choice effect ?

[aabadie]

Ok, 1b64e58 contains the correct list of dependencies required for pthread.
Can someone explain why all indirect dependencies has to be specified explicitly in Kconfig while this is not required in Make:

• In Make the dependency resolution is just (so 3 USEMODULE lines):

ifneq (,$(filter pthread,$(USEMODULE)))
  USEMODULE += ztimer64_usec
  USEMODULE += timex
  ifneq (,$(filter ztimer_xtimer_compat,$(USEMODULE)))
    # requires 64bit ftimestamps
    USEMODULE += ztimer64_xtimer_compat
  endif
endif

• In Kconfig, the equivalent becomes (8 select):

    select MODULE_PERIPH_TIMER
    select MODULE_TIMEX
    select MODULE_ZTIMER
    select MODULE_ZTIMER_PERIPH_TIMER
    select MODULE_ZTIMER64
    select MODULE_ZTIMER64_INIT
    select MODULE_ZTIMER64_USEC
    select MODULE_ZTIMER64_XTIMER_COMPAT if MODULE_ZTIMER_XTIMER_COMPAT

As a user, I would expect ztimer64, ztimer64_init, ztimer* and periph_timer to be selected automatically when ztimer_usec is selected.

[MrKevinWeiss]

Remember we are all on the same team here.

[MrKevinWeiss]

Suggested change

	select MODULE_PERIPH_TIMER
	select MODULE_TIMEX
	select MODULE_ZTIMER
	select MODULE_ZTIMER_PERIPH_TIMER
	select MODULE_ZTIMER64
	select MODULE_ZTIMER64_INIT
	select MODULE_ZTIMER64_USEC
	select MODULE_ZTIMER64_XTIMER_COMPAT if MODULE_ZTIMER_XTIMER_COMPAT
	select MODULE_ZTIMER
	select ZTIMER64_USEC
	select MODULE_ZTIMER64_XTIMER_COMPAT if MODULE_ZTIMER_XTIMER_COMPAT
	select MODULE_TIMEX

A subtle change can make the difference.

[aabadie]

I think I tried your proposal and there were still missing modules compared to make => that's the reason of my extended changes.

[MrKevinWeiss]

Due to circular dependancies in the timer abstraction layer we have a non module symbol that brings in many module symbols. This is the ZTIMER64_USEC vs the MODULE_ZTIMER64_USEC.

My guess is you used module version instead of applying the diff.

[aabadie]

My guess is you used module version instead of applying the diff.

Hmm ok, that looked like a typo... but is in fact yet another hack

[MrKevinWeiss]

Originally I was thinking to make it more explicit with a CIRCULAR_MODULE_* or something.

This was a tough one, again, we welcome input for a way around it. Ideally we would not have the circular dependency at all.

[aabadie]

Ok, finally applied your initial proposal.

[MrKevinWeiss]

Looks good (soft ACK), please squash and remove the REMOVEME commit.

[aabadie]

Squashed and REMOVEME commit removed.

[MrKevinWeiss]

ACK