"graphics" feature gate #373
Conversation
| #[cfg(feature = "graphics")] | ||
| mod tests { |
There was a problem hiding this comment.
The massive diff on this file is just because wrapping the whole code with #[cfg(feature = "graphics")] affected the indentation. Nothing is changed in actual.
CHANGELOG.md
Outdated
| @@ -52,6 +52,8 @@ | |||
|
|
|||
| - Removed `TryFrom` conversions between `Robj` and `HashMap` for consistency. `List::into_hashmap()` and `List::from_hashmap()` should be used instead. | |||
|
|
|||
| - Added support for graphics. | |||
There was a problem hiding this comment.
Perhaps mention also the feature that needs to be used to get access to graphics stuff?
There was a problem hiding this comment.
Ah, good idea. Sure.
|
It is time for |
|
I was wondering where is the best place to document it. This pull request adds it to the crate doc, but we also have
and I have no idea when to use which.... |
|
My preference: a separate PR summarizing features as a list in |
|
Sure. This pull request also adds it to the README of extendr-api crate for now. I'll create another PR for the rest. |
|
I stumbled upon this crate serial_test. Have you ever tried it out? I wonder if decorating your graphics tests with |
|
Yes, I already tried it, but it didn't save me from #370. I guess this part matters
|
|
But I didn't investigate much, so it might be worth looking it again at some point.... |
|
Thanks! The label is really useful. |
|
@andy-thomason |
|
Merging this and will address #378 |
This pull request move graphics-related features behind a feature gate because graphics is not what every user needs. I was trying to create a separate crate for graphics, but I found it's a bit difficult to untie the code that are tightly related each other.