Some modules used a 'NATIVEINCLUDES' with different include path and no other
included directories.
It was defining basic 'include' in a different order and not using other things
defined in INCLUDES.
After doing some checks with the given include path and possible conflicting
files, there should be no conflict when using the default one.
* No common headers between all the NATIVEINCLUDES directories
* No common headers files between board/native/include, cpu/native/include and
other files in the repository (except other boards/cpus of course).
Currrently native overrides the object file targets, because it needs
the different include paths to interact with libc and the OS.
This PR simplifies their makefiles to only override the variable
INCLUDES, instead of overriding the targets.
Many modules have subdirectories. Often these subdirectories should only
be included under certain circumstances. Modules that use submodules
currently need to use this pattern:
```make
DIRS = …
all: $(BINDIR)$(MODULE).a
@for i in $(DIRS) ; do $(MAKE) -C $$i ; done ;
include $(RIOTBASE)/Makefile.base
clean::
@for i in $(DIRS) ; do $(MAKE) -C $$i clean ; done ;
```
This PR moves the `all:` and `clean::` boilerplate into `Makefile.base`.
Closes#993.
We do not need to descend into the modules to know what to do on
`make clean BOARD=blub`. We can just invoke `rm -rf bin/blub`.
This PR only keeps the descending into the USEPKGs, since they might
want to delete cached/downloaded/extracted data.
native modules will never need the dynamic INCLUDES, so we define our
own NATIVEINCLUDES. Due to the current make structure, the only way to
not use INCLUDES is to redefine the build rules.