You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's somewhat related to the issue I have here: #1460
I now modified my approach to instead of attempting to statically link HDF5, I dynamically link it, but then I distribute two binaries, one that needs a system HDF5 installation and one that doesn't. I use a feature to guard the HDF5 dependency.
Then I run into the yet unsolved issue of workspace feature unification there's a (merged) RFC as well but it is a hard problem. If I just build with cargo build -p plotinator3000 I get a binary that does not link to hdf5, but if I build with cargo build --bins then both link to hdf5 because of the workspace feature unification issue.
This is where dist comes into the picture because how does dist build the binaries? Evidently through something like cargo build --bins because both binaries built by dist link to HDF5.
e.g. in this action log I build a workspace with multiple binaries (plotinator3000 and plotinator3000-h5), such that users can run a binary that doesn't require an HDF5 dynamic library on the system if they don't need HDF5 support. The example is the apple build but it is the same for all builds.
If I could control the build to use cargo build -p plotinator3000 and cargo build -p plotinator3000-h5 then I achieve what I need without having to wait for the Cargo team to figure out and implement workspace feature unification configuration options.
This issue of HDF5 linkage is becoming more and more of an issue for my project, I really want to keep using dist because it is a major benefit, but if I can't solve this issue in a way that doesn't bother users, then I have to consider another approach. I'm very open to suggestions btw, maybe there's a much better approach that I'm totally missing.
The text was updated successfully, but these errors were encountered:
Description
It's somewhat related to the issue I have here: #1460
I now modified my approach to instead of attempting to statically link HDF5, I dynamically link it, but then I distribute two binaries, one that needs a system HDF5 installation and one that doesn't. I use a feature to guard the HDF5 dependency.
Then I run into the yet unsolved issue of workspace feature unification there's a (merged) RFC as well but it is a hard problem. If I just build with
cargo build -p plotinator3000
I get a binary that does not link to hdf5, but if I build withcargo build --bins
then both link to hdf5 because of the workspace feature unification issue.This is where
dist
comes into the picture because how doesdist
build the binaries? Evidently through something likecargo build --bins
because both binaries built bydist
link toHDF5
.e.g. in this action log I build a workspace with multiple binaries (
plotinator3000
andplotinator3000-h5
), such that users can run a binary that doesn't require an HDF5 dynamic library on the system if they don't need HDF5 support. The example is the apple build but it is the same for all builds.Proposed solution
If I could control the build to use
cargo build -p plotinator3000
andcargo build -p plotinator3000-h5
then I achieve what I need without having to wait for the Cargo team to figure out and implement workspace feature unification configuration options.This issue of HDF5 linkage is becoming more and more of an issue for my project, I really want to keep using
dist
because it is a major benefit, but if I can't solve this issue in a way that doesn't bother users, then I have to consider another approach. I'm very open to suggestions btw, maybe there's a much better approach that I'm totally missing.The text was updated successfully, but these errors were encountered: