Repository navigation
Hide test binaries behind a feature flag #23
Description
Activity
This is only a possibility if the alternatives don't work. I'd try to avoid complicating the project with features that have followup complications. Thus first test:
- if "cargo install split-patch" (and we haven't even published it yet) doesn't do the right thing of only installing the binary under src/bin/ (remember I haven't verified)
- Then, given that we want to document in the README that it should probably be "cargo install --locked split-patch" anyway, whether just also adding "--bin split-patch" is really so bad.
- Then, we could also move the test infrastructure binaries to a separate crate. This is likely better than the feature flag.
Reacted by Yusuf RajiShould also make the binary theoretically smaller
Each binary is compiled separately, so it will have no effect on the size of split-patch binary if that's what you meant.
So I suggest to do in order:
- Move main crate to a subdir, too (Move split-patch crate to a subdir, too #14)
- Implement workspace (Configure workspaces #10)
- Decide on license for the split-patch crate together (Add license to the split-patch crate #11), publish on crates.io
- Test what cargo install does, decide what to do about it.
Reacted by Yusuf RajiShould also make the binary theoretically smaller
Each binary is compiled separately, so it will have no effect on the size of split-patch binary if that's what you meant.
Yes, that's what I meant. It should be alright in that case.
split-patch now has two rust binaries used in tests. This number could increase in the future. And it is possible that the binaries are made available to any installs split-patch via cargo install.
This is discussed in #21 (comment)
Hiding test binaries under a feature flag could prevent them from being bundled with the default split-patch. Should also make the binary theoretically smaller.