-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reimplement log-logging feature #92
Conversation
That is an awesome way to do it! Can't believe i haven't though of that! 🧐 Looks good at first glance! 👍 |
I'm currently thinking about how the CI scrips should be updated. I've implemented the features such that
I think the CI should make sure that the code compiles for 1.-3. Do you agree? |
I think your condition checks might be simplified a bit by introducing a [features]
default = ["defmt-logging"]
defmt-logging = ["defmt"]
log-logging = ["log"]
defmt-default = ["defmt-logging"]
defmt-error = ["defmt-logging"]
defmt-warn = ["defmt-logging"]
defmt-debug = ["defmt-logging"]
defmt-info = ["defmt-logging"] And then making the derive for Furthermore it removes the need for defmt in your dependency graph, if you are only interested in using What you think? Regarding the CI i would agree with points 1, 2 & 3 being most relevant |
That sounds really beneficial, especially because defmt can cause linker errors when compiled for x86. Do we really need the |
I don't think a feature and an optional dependency can have the same name? 🤔 |
If the feature flag should simply enable/disable that one optional dependency, then it works. However, it cannot be used to "group" multiple optional dependencies. |
Aha, TIL 😊👍 |
(Or, in other words: If you have an optional dependency on the crate "foobar", then "foobar" will automatically be a cargo feature, without even defining it. This means that you cannot define your own custom "foobar" flag, since it would conflict.) |
Ahh that makes sense 👍 I just wasn't aware you could still |
I updated the branch:
I also tested the logging output on x86 (using
Seems to work fine. From my side, this looks ready to be integrated now. Can you review the PR please? Thanks in advance! |
Codecov Report
@@ Coverage Diff @@
## master #92 +/- ##
==========================================
+ Coverage 41.59% 42.40% +0.80%
==========================================
Files 25 25
Lines 1291 1257 -34
Branches 598 570 -28
==========================================
- Hits 537 533 -4
+ Misses 302 286 -16
+ Partials 452 438 -14
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me 👍
This is a WIP PR to reintroduce the
log-logging
feature flag (as has been discussed in #86 ).I first looked at the changes from #80 but then decided to introduce a new
LossyStr
type that's wrapping&[u8]
and implementing formatting as a str (if possible) for both defmt and core::fmt::Debug. This way, there's no need to use feature flags when callingatat_log
with a byte slice as param.I haven't fully tested the code yet, but I wanted to open the PR to gather feedback.
Have a great day ;-)