Makefile.include: remove rule to remake PKGs' Makefile.include

[jcarrano]

Contribution description

This rule is not being used, it complicates the makefile and causes make clean to permform unnecessary actions.

All packages have a Makefile.include, so the rule is not needed anyways:

1. Generating a file in the source tree is bad practice.
2. The contents of Makefile.include should be fixed.

Also, it is defined with a double colon for no reason.

Testing procedure

Everything should continue to work as always (this can be tested by the CI.)

Run make clean from the RIOT base with and without this commit. Without this commit you will see that there are several Makefile.include that are processed for nothing.

Issues/PRs references

Undoes part of #576.
Depends on #10456 (fixes weird make concurrency issues).

[cladmi]

This next line should go away too.

[jcarrano]

done

[cladmi]

This is in theory an API change as a package could rely on this rule to define a dynamic Makefile.include but I agree it should not be done this way. A dynamic behavior depending on the current board can still be done Makefile.include directly.

Also currently, no packages are using this at all as they all define a Makefile.include:

for pkg in  pkg/*/; do test -f ${pkg}/Makefile.include || echo NO MAKEFILE.INCLUDE for ${pkg}; done
# nothing

even if a package could be without a Makefile.include without problem, if it only provides an implementation for an API that is in RIOT so does not need any additional header path.

[cladmi]

This also removes unneeded output

make --no-print-directory -C tests/unittests/ clean
make: Nothing to be done for 'clean'.

In master.

make --no-print-directory -C tests/unittests/ clean
make[1]: Nothing to be done for 'Makefile.include'.
make[1]: Nothing to be done for 'Makefile.include'.
make[1]: Nothing to be done for 'Makefile.include'.
make[1]: Nothing to be done for 'Makefile.include'.
make[1]: Nothing to be done for 'Makefile.include'.
make: Nothing to be done for 'clean'.

I even needed to remove them for the Release-Specs test script:

https://github.com/RIOT-OS/Release-Specs/blob/a89920e1d9feb078f54aca56deebd9c04d10266c/02-tests/compile_and_test_for_board.py#L267-L276

[cladmi]

By checking for other usage of RIOTPKG/*/Makefile.include I found another line that should be cleaned: (git grep -n Makefile.include | grep PKG)

 all $(BASELIBS) $(USEPKG:%=$(RIOTPKG)/%/Makefile.include) $(BUILDDEPS): clean

https://github.com/RIOT-OS/RIOT/pull/10344/files#diff-ebbb3165b3276a049759e5cb4e04d6a4R482

You can squash directly with this change. I would do a last check after but I should be good to ACK.

[jcarrano]

I rebased on top of #10456 . I should have just cherry-picked those three commits, but it's done already.

[cladmi]

Please rebase as #10456 is merged.

[jcarrano]

Rebased.

[cladmi]

To notify next developers ending up here by bisecting, this PR could introduce other issues where running make clean all -j breaks the build. The issue is, I think, just revealed by this PR but was already there before like in #10456.
But it worth pinging here for help.

[cladmi]

I will try running the compilation all applications for native and samr21-xpro with a sleep 5 as first command in clean to find any other possible issues.

[cladmi]

I currently cannot build in docker with this as the clean trick is not done for docker.

[cladmi]

I will do a PR.

[cladmi]

I am re-running the local tests rebased on top of #10461 .

[cladmi]

I could re-run all compilation in parallel for native and samr21-xpro

BUILD_IN_DOCKER=1 DOCKER="sudo ~/.bin/sudo_docker" ./compile_and_test_for_board.py --jobs 0 --no-test  ~/work/git/RIOT/ samr21-xpro

And also without docker.

Except one error that is unrelated, and was there before that I will fix in a dedicated PR.

Please rebase as Makefile.include conflicts.

[jcarrano]

Rebased.

This was addressed.

[cladmi]

ACK I agree with removing these Makefile.include targets.

Also the parallel building was tested.

If there are a need for something like this, it should be handled in the pkg/Makefile.include itself.

[jcarrano]

it should be handled in the pkg/Makefile.include itself.

But if it does, it should not create or modify files in the source tree.

[cladmi]

You can directly merge when murdock is green.