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
When ziggy builds his targets, the used folder is $PWD/target. When in a workspace, the target directory will be at the root of the workspace. This makes that we cannot use things like cargo clean -p to clean a single crate instead of recompiling everything.
The idea is either to implement cargo ziggy clean or use the same target directory as the workspace
The text was updated successfully, but these errors were encountered:
By default, AFL++ and our runner both build a binary file in ${target}/debug/${name}.
This means that they will overwrite themselves. I have not yet found a workaround.
On the positive side: both react in the correct way to cargo clean -p package_name, so once this is solved, we're good to go.
honggfuzz-rs does build-directory shenanigans of it's own, and cargo clean -p package_name does not work.
TBD whether we can fix this.
Couldn't we follow the same idea as cargo targets with multiples "bin" targets. Runner, afl, honggfuzz? Kind of same as now, but in the workspace target directory? The only incompatible thing would be that those targets are not included in the Cargo.toml. Or does that break cargo clean -p as its not canonical?
Or we could add ourselves as binary targets in the workspace, but that would imply changing the targeted codebase. That is not too much of an issue IMO
When ziggy builds his targets, the used folder is
$PWD/target
. When in a workspace, thetarget
directory will be at the root of the workspace. This makes that we cannot use things likecargo clean -p
to clean a single crate instead of recompiling everything.The idea is either to implement
cargo ziggy clean
or use the same target directory as the workspaceThe text was updated successfully, but these errors were encountered: