I think @maribu may also should have a look, as he proposed the build system's sanity-check.

I wonder if it wouldn't be simpler to move the include of pseudomodules.inc.mk from here:

below here:

The PSEUDOMODULES should not be relevant for the dependency resolution anyway, so we could just process them after and do within pseudomodules.inc.mk stuff like:

ifneq (,$(filter ztimer_xtimer_compat,$(USEMODULE))
  # Don't link in xtimer when ztimer_xtimer_compat is used
  PSEUDOMOUDLES += xtimer
endif

@leandrolanzieri and @fjmolinas, care to share your thoughts on this?

@leandrolanzieri and @fjmolinas, care to share your thoughts on this?

Up to recently pseudo-module where declarative I preferred that, so I lean more to what I suggested in #13661 (comment), but its not something I would insist on.

PSEUDOMODULES are already defined in Makefile.includes so I think it makes makes sense to keep these conditional definitions in Makefile.include instead of in pseudomodules.inc.mk. But the problem is that Makefile.include is not included after Makefile.dep for CPUs and BOARDs. So the problem is that now that it is not declarative we care about inclusion order, because of that until this inclusion order is fixed I would have them in pseudomodules.inc.mk as @maribu suggested.

But for me this is just an argument in favor of keeping them declarative.

But for me this is just an argument in favor of keeping them declarative.

Declarative IMO is easier to maintain.

Other than that, +1 for the sanity check.

Seem that my comment unintentionally blocked this one, that was not my intention. I don't really mind either way. We are targeting changing inclusion order pretty soon, I think we can watch out to not to add the conditional PSEUDOMODULES inclusion in BOARD or CPU Makefile.include. And keep this PR as is, @maribu any comments?

Seem that my comment unintentionally blocked this one, that was not my intention. I don't really mind either way. We are targeting changing inclusion order pretty soon, I think we can watch out to not to add the conditional PSEUDOMODULES inclusion in BOARD or CPU Makefile.include. And keep this PR as is, @maribu any comments?

@jue89 if you want to take the approach suggested by @maribu I fine as well.

I think there might be something to learn in this for the Kconfig migration. It would be good if one module could "provide" another module. Specifically, ztimer_xtimer_compat would "provide" xtimer. There are more instances of this. E.g. sock_udp could be provided by the GNRC sock API implementation, or by the lwIP sock implementation, or any other network stack implementing the sock API. (Maybe Kconfig does so anyway. But if not, this would likely be a feature we could now implement with little additional effort.)

Update: Fixed typo (no --> now), which changes the meaning of the last sentence

I think there might be something to learn in this for the Kconfig migration. It would be good if one module could "provide" another module. Specifically, ztimer_xtimer_compat would "provide" xtimer. There are more instances of this. E.g. sock_udp could be provided by the GNRC sock API implementation, or by the lwIP sock implementation, or any other network stack implementing the sock API. (Maybe Kconfig does so anyway. But if not, this would likely be a feature we could no implement with little additional effort.)

From what I understand what you are referring too will be easy to model in Kconfig, in our current structure what it needs it a module that just represents the api. In the example above that could be xtimer that could be provided by xtimer_on_xtimer or xtimer_on_ztimer. Same for sock_udp. You would have the api and the choice of implementation, that would require having PSEUDOMODULES for those api modules. My suggestion in #13661 (comment) went a little bit in that direction but not quite that.

Anyway, this might be something we will need to address eventually when trying to migrate dependency resolution or otherwise it might be difficult to compare with kconfig. I kconfig terms I could see this as (ping @leandrolanzieri on this :) ):

config MOD_XTIMER
    bool
    depends on MOD_XTIMER_ON_ZTIMER || MOD_XTIMER_ON_XTIMER

An the USEMODULE equivalent:

ifneq (,$(filter xtimer,$(USEMODULE)))
  ifneq (,$(filter ztimer_xtimer_compat,$(USEMODULE)))
    USEMODULE += xtimer_on_xtimer
  endif
endif

xtimer_on_xtimer would currently still need to do the inclusion of the SRC, or be its own module and xtimer a PSEUDOMODULE.

Anyway, my two last comments, are addressing a broader subject than this PR. I still like this PR in the sense that the exception is contained, and a static check is added to avoid it being added in Makefile.dep. The broader subject can be addressed in another PR.

So ACK, on my side @maribu, I take your thumbs up as you being OK with the PR as well. I'll merge tomorrow in case you want to add something else :)

Hmm, I wonder if it might make sense to tread modules and APIs completely independent. So that a module is no longer allowed to depend on a module, but rather on an API. And the xtimer module would just be one implementation of the xtimer API, with the ztimer_xtimer_compat being another implementation of the xtimer API.

This distinction would allow adding alternative implementations of an API later on quite easily. It should also allow detecting conflicts easier. E.g. if two modules provide the same API, they implicitly conflict.

Regarding the PR: I'm fine with merging :-)

Hmm, I wonder if it might make sense to tread modules and APIs completely independent. So that a module is no longer allowed to depend on a module, but rather on an API. And the xtimer module would just be one implementation of the xtimer API, with the ztimer_xtimer_compat being another implementation of the xtimer API.

This distinction would allow adding alternative implementations of an API later on quite easily. It should also allow detecting conflicts easier. E.g. if two modules provide the same API, they implicitly conflict.

Would be nice to have @leandrolanzieri point of view on this.

Hmm, I wonder if it might make sense to tread modules and APIs completely independent. So that a module is no longer allowed to depend on a module, but rather on an API. And the xtimer module would just be one implementation of the xtimer API, with the ztimer_xtimer_compat being another implementation of the xtimer API.
This distinction would allow adding alternative implementations of an API later on quite easily. It should also allow detecting conflicts easier. E.g. if two modules provide the same API, they implicitly conflict.

Yes. I think in Kconfig this can be modelled as features provided by modules. Module A uses the B API in its code, so Module A depends on the feature HAS_B. If Module C and Module D implement the API they provide the feature when included. To make them mutually exclusive though, the symbols should be modelled inside a choice.

config MOD_A
    bool "A support"
    depends on HAS_B

config HAS_B
    bool
    help
        Indicates that B API is implemented.

choice
    bool "B implementation"

config MOD_C
    bool "C"
    select HAS_B

config MOD_D
    bool "D"
    select HAS_B

endchoice