Conversation
|
I'm all in favor of simplifying the configurations in the repo. Having a look at this change there's a lot I don't quite understand. For one, since crate features are public I'm not a fan of having a feature that would only be useful for developers. If folks want to profile, they can bring what they need into their dependencies on their own. I think this is enough motivation to instead maintain a For this PR, can we 1. remove the Thanks for drawing attention to this, should definitely not be in master. |
|
Good point on the public feature flags, didn't think of that. I'll dial this back to just dropping the config for now. I am curious about a system that uses build.rs and maybe environment variable to enable certain developer features like the debug console. Then a just recipe could set them for the dev and it would have a nice discoverable interface. But feels a little much at the moment. |
nyonson
force-pushed
the
chore/tokio-console
branch
from
337fb9a to
a3bd008
Compare
|
There's also a couple comments in |
Avoids accidental thrashing in the checked in file. If this is a feature we want for development, we have a few ideas such as a dev branch or leveraging the build.rs system. But currently not enough demand.
nyonson
force-pushed
the
chore/tokio-console
branch
from
a3bd008 to
698bf42
Compare
Oops, missed those. Cleaned up in recent commit. |
|
ACK 698bf42 Thanks |
2 participants
Instead of relying on dirty-ing a checked in file (
.cargo/config.toml), switch to a feature flag based flow to enable the tokio debug console. This avoids accidental thrashing in the checked in file. It also allows a discoverable path from the justfile for new developers.This is my first foray into the
build.rssystem, but it seems pretty straightforward. Also trying to be better about conventional commit messages.Edit: Dropped all changes except for removing the cargo configs for now.