With #10970 only existing *.c files will be added to SRC when using
the SUBMODULES mechanism, so SUBMODULES_NOFORCE (used to filter out
non existing source files) is now redundant so remove the usage.
When providing a pseudo-submodule for a module already using the
`SUBMODULES` mechanism to provide submodules, it is not possible to
create a true pseudo-module as submodule (i.e. one without any code on
its own), since the build system currently always expects there to be a
C file `module_submodule.c`.
This removes this requirement.
This adds a check to decide if Kconfig should run on a build. It will
run if any of the following conditions is true:
- A file with '.config' extension is present in the application folder
- A 'Kconfig' file is present in the application folder
- A previous configuration file is present (e.g. from a previous call to
menuconfig)
- menuconfig is being called
This assumes that Kconfig will not generate any default configurations
just from the Kconfig files outside the application folder (i.e. module
configuration via Kconfig is disabled by default). Should this change,
the check would not longer be valid, and Kconfig would have to run on
every build.
- The autoconf.h header file, generated with the current Kconfig
configurations, is added as a build dependency.
- autoconf.h depends on the proper tool (genconfig) and a Kconfig.dep
which contains the dependencies for the given application and board,
this is generated from $(USEMODULE).
- The menuconfig target is added, to allow the configuration of modules
using the Kconfig system.
By passing the -MT flag with the absolute path to the object we make
sure that the compiler generates dependency files with rules that match
our building rules.
This fixes the following issues:
* Use of 'realpath' not supported on mac
* Call of 'realpath' once for each file instead of one per archive
* Do not trigger 'llvm-ar' bug when invoked in the object directory.
llvm-ar rcTs ../m.a obj.o # Bugged
llvm-ar rcTs m.a m/obj.o # working
Using relative path linking is required to have a valid thin archive
path in the host when build in docker.
Normal, or thick archives contain a copy of the object code. Thin
archives, on the contrary, are just an index to the .o files.
This patch does two things:
1. Change ARFLAGS to enable the "T" options.
2. Call AR with all relative paths.
The second step is necessary because the build system handles all
absolute paths. If the index in the thin archive contains absolute
paths, archives created in docker are no usable outside, and moving
the objects breaks the archive.
If all arguments to AR are relative, the resulting archive contains
filenames *relative to the .a file* and nothing should break as long
as the relative location of the .a and .o remains unchanged.
Compilation time is unchanged, but disc usage is reduced by approximately
50%. These are the result of a full RIOT build:
| Thin Archive | no | yes | Savings (%) |
| -------------- | ------: | ----: | ----------- |
| pkg (10e6 KiB) | 1 790 | 905 | 49% |
| Non pkg | 71 | 71 | 1% |
| Total | 1 812 | 976 | 46 % |
AR incrementally adds file without removing files.
If a c file is deleted or disabled(submodule removal) it is not removed from
archive and still ends up in the final elf file.
This fix removes the need to do 'make clean' for this case.
However it will break cases where an APPLICATION and a MODULE or two modules
have the same name and only worked because source files names where different.
Assembly files '.S' are compiled with a subset of CFLAGS.
This means also `-include '$(RIOTBUILD_CONFIG_HEADER_C)'` so they should be
recompiled when it updates.
Currently you need to add every new sys and driver module into the
respective Makefile. This requires rebasing if another module was merged
in the meantime.
This PR allows you to omit the entry to {sys,drivers}/Makefile, if the
subfolder has the same name as the module name, which should be sensible
in most cases.
This fixes an error which was introduced by commit
346313bf07
The timestamp of directories is updated when a file inside a directory
is changed.
Therefore, make decides a target needs to be rebuilt, whenever that
target depends on its parent directory, because the directory is
always newer than the file inside.
http://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Prerequisite-Types.html
Occasionally, however, you have a situation where you want to
impose a specific ordering on the rules to be invoked without
forcing the target to be updated if one of those rules is
executed. In that case, you want to define order-only
prerequisites. Order-only prerequisites can be specified by
placing a pipe symbol (|) in the prerequisites list: any
prerequisites to the left of the pipe symbol are normal; any
prerequisites to the right are order-only:
targets : normal-prerequisites | order-only-prerequisites
Almost everything was build sequentially in RIOT, because we employed
explicit for-loops to build directories (DIRS). This PR makes our make
system use normal dependencies to build directories.
All our compiling rules were duplicated, once for the application, once
for modules. This PR makes the application a normal module, removing
this duplication.
