Update the FEATURES_OPTIONAL meaning to be more in line since
FEATURES_USED is defined. Handle FEATURES_OPTIONAL as a configuration from
the BSP/build that should not be changed anymore after.
`FEATURES_OPTIONAL` are by definition optional so are not supposed to
cause a build to fail.
Only the 'REQUIRED' ones that are not 'PROVIDED' are 'MISSING'.
* Do not change FEATURES_OPTIONAL to remove REQUIRED features
* Prepare for having a different variable for the previous value
* Update dependency resolution/info-build as FEATURES_OPTIONAL cannot be missing
This will allow sharing it between Makefile.include and
makefiles/info-global.inc.mk.
Also some common variables definition can also be moved to here.
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
My system (Ubuntu 16.04) creates a backup when opening a file with
`vim`. This backup is called `filename~`. Due to it being a copy of the
file before opening, it also is executable, which is why it is selected
for execution with the `make test` target.
This change makes the `TESTS` macro exclude files ending in `~`. This
way files ending in `~` are not executed with `make test`.
Since e.g. projects like NextCloud are excluding such files also from
their sync [[1]], I think this is fine.
[1]: d7b881feb6/sync-exclude.lst (L3)
This allows querying the build system if there are test available.
Before, one should rely on 'info-debug-variable-TESTS' to print the list
of test files. But was not reliable as sometime the build system printed
messages anyway.
BOARD=esp32-wroom-32 make --silent --no-print-directory \
-C examples/hello-world/ info-debug-variable-TESTS
ESP32_SDK_DIR should be defined as /path/to/esp-idf directory
ESP32_SDK_DIR is set by default to /opt/esp/esp-idf
# empty line here
Now the return code can be trusted.
Include the 'riotboot.mk' file before using FLASHFILE/ELFFILE/HEXFILE
variables. This will allow setting variables to values from riotboot.mk
like `FLASHFILE = $(RIOTBOOT_COMBINED_BIN)` before it is evaluated in
Makefile.include.
It should be included after defining 'BINFILE' for 'riotboot.bin'
handling.
Introduce FLASHFILE variable to start migrating boards to use it.
This is the file that will be used for flashing.
Boards do not currently use it but will migrated in upcoming PRs.
This allows setting other GLOBAL_GOALS by setting it before.
This could be the case for the application `Makefile` or files parsed
from `RIOT_MAKEFILES_GLOBAL_PRE`.
This introduces a new environment variable for a common directory
that holds all output of the build process, such as application or
package binaries. This would also allow to easily redirect output
to any other location, e.g. for out-of-source builds.
riotboot is introduced here and makes use of riotboot_hdr,
which indentifies the images encapsulated as slots.
The slot size and offset is configurable, which makes
slots extendable if needed, e.g. 2 or more slots can be
transparently added.
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Co-authored-by: Gaëtan Harter <gaetan.harter@fu-berlin.de>
When flash-only was introduced (in #8373), the `flash` rule was
made conditionally dependent on `all` by looking for `flash-only`
in MAKECMDGOALS. This was done to avoid code duplication.
There's a cleaner way, by using canned recipes. When we upgrade the
requirements to gnu make 4, the flash recipe can be defined as ?=.
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.
Also, it is defined with a double colon for no reason.
This allows specifying a list of files that should be parsed by make at
the beginning and at the end of Makefile.include.
It is a generic mechanism to allow specifying system wide configuration:
* Globally overwrite the 'TERMPROG'
* Specify a hard written port / debug_adapter_id for some BOARD values
* Define you own specific targets
* Override default targets
It can include file before and after Makefile.include to allow handling
different configurations.
When building in parallel, clean is done at the same time as the
container starts building.
So the parallel `clean all` handling should also be done for the
`..in-docker-container` target.
Makefile.include contained logic to clone a different RIOT version and
build the application against it. This can be easily achieved by making
a git worktree and overriding RIOTBASE, without adding any complexity
to our makefiles. Therefore, the feature is being removed.
When an application only includes Makefile.include without specifying
RIOTBASE and uses a `Makefile.local` file, RIOTBASE would use a wrong
default value and get the value of the directory where `Makefile.local` is.
The hostname does not provide any additional or necessary information to
the RIOT_VERSION string. On the contrary, some might consider the hostname
as personal information, which should not be exposed unsolicitedly.
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.
It fixes issues with the current rule that it is wrong that each
`$(BINDIR)/pkgname.a` is built by going in the package directory:
* `nordic_softdevice_ble.a` is built using `DIRS` and so the
`$(APPLICATION_MODULE).a` target.
* It prevents having packages that are pseudomodules, which may be
required to only use one "library" part of a package.
It also simplifies handling changes in 'ld -r' PR that could produce
objects instead of archives for packages.
Limitation of the current implementation
----------------------------------------
It removes rules being 'file' target and makes them depend on `.PHONY`
targets so always forces re-build.
But having a file target whose file is silently generated by another
target does not trigger a rebuild in Make.
They may have been declared as `order-only` prerequisites but as there are
some edge-cases that may not always work and does not currently add anything,
it was decided to keep them as normal prerequisites until it can be
globally solved.
Now also print warnings if there are missing features or a blacklisted
board when doing 'make flash'
Before, only when doing 'make' or 'make all' the FEATURES_REQUIRED,
BOARD_BLACKLIST/WHITELIST and TOOLCHAINS were checked and a warning was printed.
However as 'flash' triggers 'all' it is a common case to do 'make flash'
directly instead of 'make all flash'. So better also print warnings in
this case.
Assuming `TOOLCHAIN_SUPPORTED` is provided by the board and
`TOOLCHAIN_BLACKLIST` by a module or `pkg`, this outputs the fact that
a toolchain is not supported or blacklisted in a similar manner as
(un-)supported features and boards are.
