18803: dist/tools: Add compile_like_murdock r=benpicco a=MrKevinWeiss
### Contribution description
Helper script to pre-test murdock build conditions.
This is intended to compile like murdock giving control for only a subset of boards or applications. One can use this if only a limited change should be build tested. Defaults boards and apps are selected to be an early warning if something is wrong.
This should be used before triggering much larger murdock builds.
The following use cases are:
I made a change to something in the stm32 clocks... ./compile_like_murdock.py -c stm32
I changed a driver the DHT driver
./compile_like_murdock.py -a tests/driver_dht tests/saul
I changed a nucleo-f103rb board...
./compile_like_murdock.py -a tests/driver_dht tests/saul
### Testing procedure
View the help...
```
./dist/tools/compile_test/compile_like_murdock.py -h
```
Do a dry run of the cpu...
```
./dist/tools/compile_test/compile_like_murdock.py -c stm -d
```
Play with each of the args, try adding a module to hello-world to get a module mismatch.
### Issues/PRs references
<!--
Examples: Fixes#1234. See also #5678. Depends on PR #9876.
Please use keywords (e.g., fixes, resolve) with the links to the issues you
resolved, this way they will be automatically closed when your pull request
is merged. See https://help.github.com/articles/closing-issues-using-keywords/.
-->
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Helper script to pre-test murdock build conditions.
This is intended to compile like murdock giving control for only a subset of
boards or applications. One can use this if only a limited change should be
build tested. Defaults boards and apps are selected to be an early warning
if something is wrong.
This should be used before triggering much larger murdock builds.
The following use cases are:
I made a change to something in the stm32 clocks...
./compile_like_murdock.py -c stm32
I changed a driver the DHT driver
./compile_like_murdock.py -a tests/driver_dht tests/saul
I changed a nucleo-f103rb board...
./compile_like_murdock.py -a tests/driver_dht tests/saul
For some TTY interfaces no DB entry exists, which is reflected by
having a `None` in `tty[key]`. Trying to match a regex against `None`
in turn resulted then in an exception.
This fixes the issue by treating a filter applied on a non-existing
entry as not matching.
It turned out that 4983f8bb60 was not
enough to allow the tool to be executed from within
`dist/tools/backport_pr`. With this, I successfully tested it :)
Add `search_parent_directories=True` to `git.Repo()` so that
`backport_pr.py` can be called anywhere within the RIOT git repo
without manually passing the repo root path via `--gitdir`.
Previously the tool had to be called from the RIOT base repo.
flatc uses `strto<foo>_l()` over `strto<foo>()` when available, so that
they behave reproducible. The musl libc has no locale support, which
has the added benefit of reproducible behavior being the default.
For some reason a `strtof_l()` compatibility wrapper was added in
musl, but the other `strto<foo>_l()` wrappers are missing. This
adds a patch to check for `strtoull_l()` instead of `strtof_l()`. This
will not make a difference on a libc that supports all of them, but
fixes compilation on musl.
The argument regif was removed from the shell command in https://github.com/RIOT-OS/RIOT/pull/18053,
so there is not much need to keep it in the ShellInteraction for that command.