-
Notifications
You must be signed in to change notification settings - Fork 95
Experimental docs.rs changes #181
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
Conversation
I added a commit to move |
Cool, thanks - I've noticed the issue with So what do you think about |
(Also note the question about other |
The |
I think version numbers alone are fine if we document this on the entry page of |
Some observations:
|
We are not using much new functionality from |
|
For Agreed re: keeping numbers alone and mentioning it in the docs / Cargo.toml / changelog. Re: Re: Feature-dependent enums should probably be marked as non-exhaustive, indeed. |
Could be a doc/hdf5/types/struct.VarLenUnicode.html
doc/hdf5/types/struct.VarLenArray.html
doc/hdf5/types/struct.FixedAscii.html
doc/hdf5/types/struct.FixedUnicode.html
doc/hdf5/types/struct.VarLenAscii.html
doc/hdf5/struct.SimpleExtents.html
doc/hdf5/struct.Hyperslab.html And another variant for |
|
34fdc70
to
2e71218
Compare
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.
Most items should now be feature gated such that they appear correctly on docs.rs. Marking enums as non_exhaustive
, would a breaking change and should wait until the next major version.
@@ -16,6 +16,10 @@ default = [] | |||
mpio = ["mpi-sys", "hdf5-sys/mpio"] | |||
lzf = ["lzf-sys", "errno"] | |||
blosc = ["blosc-sys"] | |||
# The features with version numbers such as 1.10.3, 1.12.0 are metafeatures | |||
# and is only available when the HDF5 library is at least this version. | |||
# Features have_direct and have_parallel are also metafeatures and dependent |
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.
@mulimoen have_direct
and have_parallel
are not features as of now. Should we make them features as well? I.e., feature = "have-direct"
and feature = "have-parallel"
, so that they show up the same way as versions?
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.
Oh yeah, that is of course better, I assumed they would show up, but it seems not
build.rs
Outdated
"DEP_HDF5_HAVE_PARALLEL" => "h5_have_parallel".into(), | ||
"DEP_HDF5_HAVE_THREADSAFE" => "h5_have_threadsafe".into(), | ||
"DEP_HDF5_MSVC_DLL_INDIRECTION" => "h5_dll_indirection".into(), | ||
"DEP_HDF5_HAVE_DIRECT" => "have_direct".into(), |
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.
Wonder, should we have _
-> -
and make all of these feature=
?
src/hl/dataset.rs
Outdated
@@ -907,8 +907,12 @@ macro_rules! impl_builder { | |||
self.builder.$name($($var),*); self | |||
} | |||
}; | |||
($plist:ident: $name:ident($($var:ident: $ty:ty),*)) => { | |||
($(#[cfg(feature = $feature:literal)])* |
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.
Just wondering, wouldn't something like #[cfg($tt:tt)]
work, so you wouldn't have to hard-code specific syntax here?
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.
I think I tried, but this was not as straight forward as I thought. My experience with macros is too limited to see what went wrong in this instance
(Was away for a little while, back now) Wonder, for the docs.rs build, will we be able to get all the have-parallel, have-direct, etc entries show up? (and what can we do in order to make it work?) |
@@ -112,7 +115,7 @@ extern "C" { | |||
) -> htri_t; | |||
} | |||
|
|||
#[cfg(any(hdf5_1_12_0, hdf5_1_10_7))] |
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.
@mulimoen Btw, what's this?... Shouldn't this be equivalent to just 1.10.7
?
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.
Yes, that is equivalent. The function was backported so I kept hdf5_1_12_0
for simplicity. It is superfluous now
@mulimoen Looks good to merge? (I'll probably update the changelog a bit) We still need to figure how to build docs on:
(but that's a separate issue) |
Enabled this for |
doc_cfg
for nightly builds (on docs.rs and locally if enabled)hdf5_1_2_3
config flags withfeature = "1.2.3"
. This will produce annotations like "Enabled on crate feature 1.10.0 only" in the docs instead of "Enabled onhdf5_1_10_0
only". If I understand correctly, this will also allow the users to refer to these ashdf5/1.10.0
externally (?). Features can be named as "hdf5-1.10.0" but that would look a bit ugly in the docs (with the numbers only, it looks pretty neat, see below for examples).h5_have_parallel
and such be renamed tofeature = "have-parallel"
?Note: support for period for feature names has been only recently added to cargo (circa 1.50).
Related: #141.