Directories listed in this variable are added to include and
source (vpath) search paths.
Contents of this variable aren't automatically prefixed with
Contki root. This allows for inclusion of folders that are
outside Contiki root.
The commit bddd96d5c8 "Removed all module
makefiles. Instead, all .c files in a module directory are compiled."
made the MODULESSUBST variable useless, but it did not remove it, so do
it now.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
By changing RELSTR= into RELSTR:= we force Make to evaluate the Git
version string only during Makefile read, and not on every single build
command execution.
The reduction in file system I/O cut the time to build
examples/er-rest-example on my development machine by a significant
amount, see below.
Core i7 notebook with ext4 file system on an SSD (building for TARGET=mulle):
"RELSTR=" make 19.70s user 1.07s system 82% cpu 25.291 total
"RELSTR:=" make 11.81s user 1.27s system 79% cpu 16.499 total
Signed-off-by: Joakim Gebart <joakim.gebart@eistec.se>
rm -f can still fail, e.g., if trying to delete a directory.
If there was, say, a directory called "core", a "make clean" would
therefore only try to delete the files listed in the first command but
not proceed with the rest of the cleanup.
"make clean" itself failing may also affect any outside build process
that invokes it.
This should be more friendly to legacy operating systems that
don't support multiple shell commands per line. Note that
architecture-specific overrides need to be adapted, if verbosity
control is desired for them as well.
This shortens $(CC) and $(AR) lines to a much more readable length,
making warnings stick out clearly.
The spaces after "CC" and "AR" are to reserve space for other operations
that may use longer names, such as the communly found "BUILD" or
"GENERATE".
Historically $(OBJECTDIR) was created when Makefile.include is read. A
consequence is that combining "clean" with "all" (or any other build
target) results in an error because the clean removes the object
directory that is required to exist when building dependencies.
Creating $(OBJECTDIR) on-demand ensures it is present when needed.
Removed creation of $(OBJECTDIR) on initial read, and added an order-only
dependency forcing its creation all Makefile* rules where the target is
explicitly or implicitly in $(OBJECTDIR).
This commit moves the Settings Manager from the AVR codebase
into the Contiki core library. Any platform that implements
the Contiki EEPROM API can now use the Settings Manager's
key-value store for storing their persistent configuration info.
The Settings Manager is a EEPROM-based key-value store. Keys
are 16-bit integers and values may be up to 16,383 bytes long.
It is intended to be used to store configuration-related information,
like network settings, radio channels, etc.
* Robust data format which requires no initialization.
* Supports multiple values with the same key.
* Data can be appended without erasing EEPROM.
* Max size of settings data can be easily increased in the future,
as long as it doesn't overlap with application data.
The format was inspired by the [OLPC manufacturing data format][].
Since the beginning of EEPROM often contains application-specific
information, the best place to store settings is at the end of EEPROM
(the "top"). Because we are starting at the end of EEPROM, it makes
sense to grow the list of key-value pairs downward, toward the start of
EEPROM.
Each key-value pair is stored in memory in the following format:
Order | Size | Name | Description
--------:|---------:|--------------|-------------------------------
0 | 2 | `key` | 16-bit key
-2 | 1 | `size_check` | One's-complement of next byte
-3 | 1 or 2 | `size` | The size of `value`, in bytes
-4 or -5 | variable | `value` | Value associated with `key`
The end of the key-value pairs is denoted by the first invalid entry.
An invalid entry has any of the following attributes:
* The `size_check` byte doesn't match the one's compliment of the
`size` byte (or `size_low` byte).
* The key has a value of 0x0000.
[OLPC manufacturing data format]: http://wiki.laptop.org/go/Manufacturing_data
