Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

makefiles/dependency_resolution: add outer loop for DEFAULT_MODULE deps #17632

Merged
merged 3 commits into from
Feb 14, 2022

Conversation

fjmolinas
Copy link
Contributor

Contribution description

Some DEFAULT_MODULEs in tree have dependencies of their own. This is
usually done for aliases of init modules, and do not have dependencies
themselves.

This adds the final stage to dependency resolutions where DEFAULT_MODULEs
dependencies MAY be included. These included modules MUST NOT have
dependencies themselves.

This allows for modules to disable DEFAULT_MODULEs during dependencies
resolution independent of the inclusion order.

auto_init and periph_init modules are moved to this outer-loop, allowing
therefore for modules to disable them during the dependency resolution

Testing procedure

Dependencies should not have changed.

Issues/PRs references

Could be used by #17584

@fjmolinas fjmolinas requested a review from maribu February 9, 2022 13:45
@github-actions github-actions bot added Area: build system Area: Build system Area: sys Area: System Area: timers Area: timer subsystems labels Feb 9, 2022
@fjmolinas fjmolinas added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Feb 9, 2022
@fjmolinas fjmolinas added the Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation label Feb 10, 2022
@benpicco
Copy link
Contributor

Looks like something broke

@fjmolinas
Copy link
Contributor Author

@benpicco all green, can I squash? I run the dependency check script in parallel after I squash

@benpicco
Copy link
Contributor

Yes please squash!

Copy link
Contributor

@benpicco benpicco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me

@fjmolinas
Copy link
Contributor Author

I ran the save_dependency_debug script, there were some differences, but IMO they are expected, basically in some cases xtimer and ztimer would get select instead of ztimer, this depends on inclusion order for some applications and boils down to the fact that now gnrc_netif_init_devs becomes a MODULE at the end. Although this module does not have explicit dependencies it has some because of wildcards:

ifneq (,$(filter gnrc_netif_%,$(USEMODULE)))
  USEMODULE += gnrc_netif
endif

ifneq (,$(filter gnrc_netif,$(USEMODULE)))
  USEMODULE += netif
  USEMODULE += l2util
  USEMODULE += fmt
  USEMODULE += ztimer_msec
  ...
endif

So with de previous DEFAULT_MODULE inclusion ztimer_msec got included early on and the when conditional xtimer/ztimer dependencies arrived xtimer was not included:

# unless ztimer_xtimer_compat is used, make xtimer use ztimer_usec as backend.
ifneq (,$(filter ztimer_periph_timer,$(USEMODULE)))
  ifneq  (,$(filter xtimer,$(USEMODULE)))
    ifeq (,$(filter ztimer_xtimer_compat,$(USEMODULE)))
      USEMODULE += xtimer_on_ztimer
    endif
  endif
  ifneq (,$(filter evtimer,$(USEMODULE)))
    USEMODULE += evtimer_on_ztimer
  endif
endif

IMO these differences are OK, since they are based in changes in order of inclusions, this will always happen, and simply adding USEMODULE += ztimer_* earlier would solve it for the target application.

If you agree please hit the green button @benpicco

@fjmolinas
Copy link
Contributor Author

Maybe @maribu or @leandrolanzieri would like to give it the go, since they have looked at build system a lot :)

USEMODULE += ztimer_init
endif

ifneq (,$(filter auto_init_gnrc_netif,$(USEMODULE)))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

auto_init_gnrc_netif is not a DEFAULT_MODULE

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, I thought it was because of the auto_init_ prefix..., I'll remove it from here then..

@fjmolinas
Copy link
Contributor Author

If you agree please hit the green button @benpicco

@benpicco pointed out the auto_init_gnrc_netif is not a default module, but the analysis still stands, because I had moved the gnrc_netif_% dependency against it to the end.

Modules select by auto-init modules MUST NOT have dependencies
themselfs, dhcp_relay was not respecting that. Instead of having
the auto-init module select dhcp_relay, do it the other way
around.
Some DEFAULT_MODULEs in tree have dependencies of their own. This is
usually done for aliases of init modules, and do not have dependencies
themselves.

This adds the final stage to dependency resolutions where DEFAULT_MODULEs
dependencies MAY be included. These included modules MUST NOT have
dependencies themselves.

This allows for modules to disable DEFAULT_MODULEs during dependencies
resolution independent of the inclusion order.

auto_init and periph_init modules are moved to this outer-loop, allowing
therefore for modules to disable them during the dependency resolution
@benpicco benpicco merged commit e126743 into RIOT-OS:master Feb 14, 2022
@fjmolinas fjmolinas deleted the pr_default_modules_deps branch February 14, 2022 14:43
@fjmolinas
Copy link
Contributor Author

Thanks @benpicco!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: build system Area: Build system Area: sys Area: System Area: tests Area: tests and testing framework Area: timers Area: timer subsystems CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants