Makefiles: Sorted & deduplicated rules in Makefile dep

[maribu]

Contribution description

The rules in $(RIOTBASE)/Makefile.dep that manage inter module dependencies are currently unsorted, which easily leads to duplicated rules such as

ifneq (,$(filter saul,$(USEMODULE)))
  USEMODULE += phydat
endif

[...]

ifneq (,$(filter saul,$(USEMODULE)))
  USEMODULE += phydat
endif

Sorting the rules alphabetically makes finding and extending existing rules easier and will help to prevent duplication. Also, the structure of the file was not well documented. As a result rules are easily placed at places the should not be placed.

Testing procedure

Murdock & code review. (I checked double checked that every rule to make sure I did not remove any rule by accident, but it makes sense to have many eyes checked that.

It is also worth to have a look at the impact on the build time on Murdock, as some of the rules have been sorted to let the recursive include of Makefile.dep terminate sooner. With the alphabetical sorting this is no longer the case, but most likely the additional recursions will not matter much.

Issues/PRs references

The added documentation will hopefully prevent issues similar to the one introduced in #9988 from slipping in again.

[cladmi]

One big issue with changing the "ifeq" rules order is that they do not handle dependencies but rather "policy" to select a default implementation. And this is really really hard to debug without checking in details.

And the murdock output shows issues with the lwip ordering that breaks something.
I already had the issue in the lwip when refactoring inside the packages 1be18e9

It is something I want to address but would rather first group all the dependencies to only one step (instead of having some dependency handled in boards/Makefile.include) as I describe in followed by #9913
This way, it would be way easier to process many many different configurations as it would not need to call gcc in the middle to get its supported options and getting the output to ensure there is no regression. Otherwise it needs analyzing precisely each change.

However the de-duplication should be good to do as it is easier to review.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

As per usual with cleaning up moving targets, this seems to be somewhat of a hassle. @maribu are you still interested in this?

[maribu]

As per usual with cleaning up moving targets, this seems to be somewhat of a hassle. @maribu are you still interested in this?

Actually, I still think having them sorted makes maintenance a bit easier.

But when I created this PR it took my over an hour last time to carefully check that the deduplicating and merging(*) didn't swallow up a rule.

(*) By merging I mean that:

ifneq (,$(filter foo,$(USEMODULE)))
  USEMODULE += bar
endif

...

ifneq (,$(filter foo,$(USEMODULE)))
  USEMODULE +=baz
endif

became:

ifneq (,$(filter foo,$(USEMODULE)))
  USEMODULE +=bar
  USEMODULE +=baz
endif

I have to grow some motivation before I'm able to do such a pain-in-the-ass work again.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.