This adds a list of board/application pairs which should be tested. The
test consists on comparing the binaries generated using dependency
resolution in Makefile and in Kconfig.
-gz enables DWARF section compression, though it is a no-op where debug
is not enable, e.g. in murdock.
Due to a combination of factors, including a bug in CCACHE, this flag
makes CCACHE ineffective and slows down murdock.
The alternative, of filtering the flags in our buid system (for example,
by testing RIOT_CI_BUILD or CCACHE) are too much of a shotgun approach
as the problem is quite specific to our CI setup.
Read the comment in the file for a more in-depth description.
Previously, this was hard-coded to allow one file, hard-coded to be
called "flash file".
This commit allows multiple files to be specified via adding them to the
TEST_EXTRA_FILES variable. All files will be stored in the worker's
application bin directory.
Also, the existence check has been removed, as dwqc bails out on missing
file anyways.
This change allows callers to receive the job list of individual apps in
chunks (instead of all at once after all appdirs have been processed),
if run as dwq job itself.
E.g.,
$ dwqc ./.murdock get_compile_jobs
would previously run "get_compile_jobs()" as one job, collecting all the
output from "get_app_board_toolchain_pairs()" subjobs, then return the
combined output as job result.
By using subjobs, the job returns right away, but has previously sent
the "get_app_board_toolchain_pairs" jobs as subjobs ti the initial
instance, which will also wait for all of them to complete, but
already print subjob output as it is received.
Previously, get_app_board_toolchain_pairs() took the appdir as only
parameter and produced "$appdir $board:$toolchain" tuples.
This commit makes get_app_board_toolchain_pairs() prefix each tuple with
any additional args, e.g.,
get_app_board_toolchain_pairs() tests/hello_world ./murdock compile
->
./murdock compile tests/hello_world samr21-xpro:gnu
This allows getting rid of the xargs call in get_compile_jobs().
There are two major reasons for this:
1. clang picks up different errors sometimes than GCC.
2. OSX support is hardened as it is usually the toolchain used there.