The build system contains several instances of
INCLUDES += -I$(RIOTBASE)/sys/posix/include
This is bypassing the module management system, by directly accesing
headers without depending on a module. The module is the posix module.
That line is also added when one of the posix_* modules is requested.
According to the docs, the posix module provides headers only, but in
reality there is also inet.c.
This patch:
- Moves `inet.c` into `posix_inet`, leaving `posix` as a headers-only
module.
- Rename `posix` as `posix_headers` to make it clear the module only
includes headers.
- Makes `posix_*` modules depend on `posix_headers`, thus removing the
explicit `INCLUDES+=...` in `sys/Makefile.include`.
- Ocurrences of `INCLUDES+=...` are replaced by an explicit dependency
on `posix_headers`.
riotboot_hdr enables to partition the internal flash memory
into "slots", each one with a header providing information
about the partition. The concept for now is limited to
firmware partitions, which are recognised by the riotboot
bootloader. In the future the concept might be extended to
represent other content.
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Process `Makefile.include` for external modules. It is included after the others
so it could overwrite some of the configuration if wanted.
Process `Makefile.dep` for external modules. It is included before the others so
it could be parsed before setting 'default' values to dependencies.
With out this fix the application or device drivers need to add this
module. Otherwise, compilation of the lwIP adaptation layer will fail
for Ethernet devices.
When I introduced this pseudo-module in #9391 I did not consider, that
the way I named it, it is assumed to be an implementation of the
`gnrc_pktbuf` interface. However, it is not (it just provides the shell
command).
This PR excludes `gnrc_pktbuf_cmd` from the selection algorithm, so
that if it is the only `gnrc_pktbuf_%` module, still
`gnrc_pktbuf_static` gets selected.
Provides functions for type 3, 4 and 5 UUID generations.
UUID type 1 is timestamp based and requires an accurate time source. For
this reason it is left out of this implementation. UUID type 2 is not
defined in RFC 4122 and thus also not included here