Test the backend that uses poll on CI #63
Conversation
taiki-e
force-pushed
the
taiki-e/test-poll
branch
from
37aef43 to
560a6c7
Compare
taiki-e
changed the title
| target_os = "netbsd", | ||
| target_os = "openbsd", | ||
| target_os = "dragonfly", | ||
| #[cfg(all( |
There was a problem hiding this comment.
I'm getting mildly uncomfortable with the config sprawl happening here. The easiest way to resolve it would be to emit build constants in build.rs, but I'm not sure how portable that is.
There was a problem hiding this comment.
As for cfg, another option is to move the implementation to the corresponding backend module, but doc-cfg does not work well either way.
- If we keep doc-cfg, this is the best I know of: c736dfb
- If we remove doc-cfg, we can remove those cfgs: 87def8d
(I'm fine with either of the above.)
If we remove doc-cfg and use build-script, the code will be more little simpler (f3ee746), but I don't much prefer it due to the compatibility issues mentioned in #39 (comment), some pitfalls specific to build scripts1, and the difficulty of finding typos in the build-script2.
Footnotes
-
There are pitfalls specific to build scripts, such as parsing target triples directly instead of using
CARGO_CFG_*makes it less robust. (In that case, it is mainly new or custom targets that are affected, though.) ↩ -
I have not yet introduced it in smol-rs's CI, but there is an unstable option to check for unrecognized cfgs called -Z check-cfg, and I use it in cfg-heavy projects like portable-atomic. ↩
This backend (#26) is only used on minor operating systems which is not easy for us to test.
Historically we used to do these tests by adjusting cfg on Linux or macOS. (#26 (comment), #26 (review))
This patch makes testing in such a way easy and can be run on CI.