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
Thank you for putting this together. The time watching github download and compile the rust binaries is painful. Thank you for reducing the pain!
In part to better understand and perhaps generally help, I have the following questions:
Including --bin option in chef cook - could it help?
I have a workspace. One of the members is a bin. -- Is there any benefit to having chef cook called with the specific bin in the event I only want to build that bin using cargo build? In contrast for instance, right now we have to reflect the --target <value> in each call to chef cook and cargo build. This is not the case for the specific bin we plan to build. It is not an option right now, for which there might be a good reason, so I wanted to ask.
Might using --target-dir frustrate the cache benefits of chef?
In my working with chef I get the feeling that I prevent the proper functioning of chef if I set the ---target-dir feature (something that can also be set using ENV CARGO_TARGET_DIR) to a non-default value. Said differently, does where I build the final artifact matter to chef? The cargo docs suggest using this feature to help with caching issues, perhaps "two rights make a wrong" in this case :))?
The cargo index always gets updated
When I change something in the runtime layer that has nothing to do with the build layers, the cargo index at the very top of the process insists on updating. Is that related to what used to be an issue for workspaces? (rust-lang/cargo#9393)
The text was updated successfully, but these errors were encountered:
I have a workspace. One of the members is a bin. -- Is there any benefit to having chef cook called with the specific bin in the event I only want to build that bin using cargo build? In contrast for instance, right now we have to reflect the --target in each call to chef cook and cargo build. This is not the case for the specific bin we plan to build. It is not an option right now, for which there might be a good reason, so I wanted to ask.
Yes, there is!
It would build only the dependencies needed by your binary instead of the dependencies for the whole workspace.
This can be partially achieved, today, using --manifest-path. We could definitely add the --bin flag.
Might using --target-dir frustrate the cache benefits of chef?
I am unsure about this - I'd have to check a minimal reproducible example to give a definite answer.
Thank you for putting this together. The time watching github download and compile the rust binaries is painful. Thank you for reducing the pain!
In part to better understand and perhaps generally help, I have the following questions:
Including
--bin
option inchef cook
- could it help?I have a workspace. One of the members is a bin. -- Is there any benefit to having
chef cook
called with the specific bin in the event I only want to build that bin usingcargo build
? In contrast for instance, right now we have to reflect the--target <value>
in each call tochef cook
andcargo build
. This is not the case for the specific bin we plan to build. It is not an option right now, for which there might be a good reason, so I wanted to ask.Might using
--target-dir
frustrate the cache benefits ofchef
?In my working with
chef
I get the feeling that I prevent the proper functioning ofchef
if I set the---target-dir
feature (something that can also be set usingENV CARGO_TARGET_DIR
) to a non-default value. Said differently, does where I build the final artifact matter tochef
? The cargo docs suggest using this feature to help with caching issues, perhaps "two rights make a wrong" in this case :))?The cargo index always gets updated
When I change something in the
runtime
layer that has nothing to do with the build layers, the cargo index at the very top of the process insists on updating. Is that related to what used to be an issue for workspaces? (rust-lang/cargo#9393)The text was updated successfully, but these errors were encountered: