newlib: use RIOT dependency system for _GNU_SOURCE instead #4
Conversation
| @@ -8,6 +8,12 @@ OLD_USEPKG := $(sort $(USEPKG)) | |||
| # pull dependencies from drivers | |||
| include $(RIOTBASE)/drivers/Makefile.dep | |||
|
|
|||
| ifneq (,$(filter cbor_ctime,$(USEMODULE))) | |||
| ifneq (,$(filter newlib,$(USEMODULE))) | |||
There was a problem hiding this comment.
Why this ifneq newlib here ?
There was a problem hiding this comment.
Because on e.g. native we don't need it (and it actually leads to errors)
There was a problem hiding this comment.
I would rather see the native non native special handling into newlib.mk.
In Makefile.dep we say that cbor_time needs to be able to print time. And behind the scene, make it work for every case.
There was a problem hiding this comment.
But native doesn't even use newlib as do msp430 or AVR-based platforms. Handling the absence of a module as a special case in a module seems non-sensical to me.
|
It looks a bit overkill for me, do we use that much GNU extensions? |
|
Why is it overkill? It does exactly what your proposal does, just with a cleaner integration into our build system (allowing for an easier switchover to a new build system, if required, in the future). |
|
That's what I mean, lots of definitions just for the use of If a build system change is coming, this would be the last of our problems... |
I find it weird, that a sequencing module needs |
|
@cladmi are you ok with the changes? |
|
For me its a Why not just fix it quickly so the compilation works now, add a corresponding issue and address it after the release ? |
|
That is I what this PR does.... |
|
Ok let's go with this one and we "maybe" see afterwards if it worths to change it. |
The test randomly fails on `native` due to timers being not accurate but
it cannot be otherwise. So better disable it than raising fake errors.
main(): This is RIOT! (Version: buildtest)
Testing generic evtimer
This should list 2 items
ev #1 offset=1000
ev #2 offset=500
This should list 4 items
ev #1 offset=659
ev #2 offset=341
ev #3 offset=500
ev #4 offset=2454
Are the reception times of all 4 msgs close to the supposed values?
At 662 ms received msg 0: "#2 supposed to be 659"
At 1009 ms received msg 1: "#0 supposed to be 1000"
At 1511 ms received msg 2: "#1 supposed to be 1500"
Traceback (most recent call last):
File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/tests/evtimer_msg/tests/01-run.py", line 33, in <module>
sys.exit(run(testfunc))
File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/dist/pythonlibs/testrunner/__init__.py", line 29, in run
testfunc(child)
File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/tests/evtimer_msg/tests/01-run.py", line 26, in testfunc
assert(actual in range(expected - ACCEPTED_ERROR, expected + ACCEPTED_ERROR))
AssertionError
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu ### Contribution description The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details. In addition, a SAUL layer and auto-initialization is provided. ### Testing procedure The test application provides access to the servo driver via the `saul` shell command. ``` > saul 2022-08-02 22:12:31,826 # saul 2022-08-02 22:12:31,827 # ID Class Name 2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green) 2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue) 2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red) 2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button) 2022-08-02 22:12:31,838 # #4 ACT_SERVO servo > saul write 4 0 2022-08-02 22:12:41,443 # saul write 4 0 2022-08-02 22:12:41,445 # Writing to device #4 - servo 2022-08-02 22:12:41,447 # Data: 0 2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255) 2022-08-02 22:12:41,453 # data successfully written to device #4 > saul write 4 256 2022-08-02 22:12:45,343 # saul write 4 256 2022-08-02 22:12:45,346 # Writing to device #4 - servo 2022-08-02 22:12:45,347 # Data: 256 2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255) 2022-08-02 22:12:45,354 # data successfully written to device #4 ``` Each write resulted in the MG90S servo that I connected to move to the corresponding position. ### Issues/PRs references Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
No description provided.