-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of feature flagged functions in std::cfg macro #71679
Comments
Opening this as a way of opening the discussion about an issue that I was running into. If you would prefer a different approach, I'm happy to discuss that. Within multi-language environments, such as bazel, cargo isn't always able to drive the build process. However, prost and prost-build provides an amazing foundation of which to build off. The general idea of this commit was to open up prost-build to having tools built off of it, while still preserving previous behavior. Currently, if PROTOC or PROTO_INCLUDE are not set at build-time, then the build fails. This commit introduces feature, runtime-protoc. This hides env! invocations when enabled, allowing compilation, under the assumption that the protoc location will be provided at runtime.
We can update the docs, for sure, but I'm not sure what to say -- maybe something like "this simply evaluates to true/false"? |
To rephrase, slightly, how about adding the following to the docs:
|
Opening this as a way of opening the discussion about an issue that I was running into. If you would prefer a different approach, I'm happy to discuss that. Within multi-language environments, such as bazel, cargo isn't always able to drive the build process. However, prost and prost-build provides an amazing foundation of which to build off. The general idea of this commit was to open up prost-build to having tools built off of it, while still preserving previous behavior. Currently, if PROTOC or PROTO_INCLUDE are not set at build-time, then the build fails. This commit introduces feature, runtime-protoc. This hides env! invocations when enabled, allowing compilation, under the assumption that the protoc location will be provided at runtime. This wouldn't be my first preference, but I was prioritizing the build-break if the environment flags were not specified. I would generally have preferred grabbing those with option_env! macros and then trying to gracefully handle the error at runtime protoc has not been provided at build time or runtime similar, since this is already covered by tests. That would allow removal of the feature flag. It would also make the code a little cleaner, since there's not a great way to do conditionals with cfg (see rust-lang/rust#71679).
Add clarification on std::cfg macro docs v. #[cfg] attribute The wording was discussed, to a limited degree in rust-lang#71679. This tries to address some confusion I as well as someone else had independently when looking at this macro. Fixes rust-lang#71679
Opening this as a way of opening the discussion about an issue that I was running into. If you would prefer a different approach, I'm happy to discuss that. Within multi-language environments, such as bazel, cargo isn't always able to drive the build process. However, prost and prost-build provides an amazing foundation of which to build off. The general idea of this commit was to open up prost-build to having tools built off of it, while still preserving previous behavior. Currently, if PROTOC or PROTO_INCLUDE are not set at build-time, then the build fails. This commit introduces feature, runtime-protoc. This hides env! invocations when enabled, allowing compilation, under the assumption that the protoc location will be provided at runtime. This wouldn't be my first preference, but I was prioritizing the build-break if the environment flags were not specified. I would generally have preferred grabbing those with option_env! macros and then trying to gracefully handle the error at runtime protoc has not been provided at build time or runtime similar, since this is already covered by tests. That would allow removal of the feature flag. It would also make the code a little cleaner, since there's not a great way to do conditionals with cfg (see rust-lang/rust#71679).
Opening this as a way of opening the discussion about an issue that I was running into. If you would prefer a different approach, I'm happy to discuss that. Within multi-language environments, such as bazel, cargo isn't always able to drive the build process. However, prost and prost-build provides an amazing foundation of which to build off. The general idea of this commit was to open up prost-build to having tools built off of it, while still preserving previous behavior. Currently, if PROTOC or PROTO_INCLUDE are not set at build-time, then the build fails. This commit introduces feature, runtime-protoc. This hides env! invocations when enabled, allowing compilation, under the assumption that the protoc location will be provided at runtime. This wouldn't be my first preference, but I was prioritizing the build-break if the environment flags were not specified. I would generally have preferred grabbing those with option_env! macros and then trying to gracefully handle the error at runtime protoc has not been provided at build time or runtime similar, since this is already covered by tests. That would allow removal of the feature flag. It would also make the code a little cleaner, since there's not a great way to do conditionals with cfg (see rust-lang/rust#71679).
Opening this as a way of opening the discussion about an issue that I was running into. If you would prefer a different approach, I'm happy to discuss that. Within multi-language environments, such as bazel, cargo isn't always able to drive the build process. However, prost and prost-build provides an amazing foundation of which to build off. The general idea of this commit was to open up prost-build to having tools built off of it, while still preserving previous behavior. Currently, if PROTOC or PROTO_INCLUDE are not set at build-time, then the build fails. This commit introduces feature, runtime-protoc. This hides env! invocations when enabled, allowing compilation, under the assumption that the protoc location will be provided at runtime. This wouldn't be my first preference, but I was prioritizing the build-break if the environment flags were not specified. I would generally have preferred grabbing those with option_env! macros and then trying to gracefully handle the error at runtime protoc has not been provided at build time or runtime similar, since this is already covered by tests. That would allow removal of the feature flag. It would also make the code a little cleaner, since there's not a great way to do conditionals with cfg (see rust-lang/rust#71679).
Opening this as a way of opening the discussion about an issue that I was running into. If you would prefer a different approach, I'm happy to discuss that. Within multi-language environments, such as bazel, cargo isn't always able to drive the build process. However, prost and prost-build provides an amazing foundation of which to build off. The general idea of this commit was to open up prost-build to having tools built off of it, while still preserving previous behavior. Currently, if PROTOC or PROTO_INCLUDE are not set at build-time, then the build fails. This commit introduces feature, runtime-protoc. This hides env! invocations when enabled, allowing compilation, under the assumption that the protoc location will be provided at runtime. This wouldn't be my first preference, but I was prioritizing the build-break if the environment flags were not specified. I would generally have preferred grabbing those with option_env! macros and then trying to gracefully handle the error at runtime protoc has not been provided at build time or runtime similar, since this is already covered by tests. That would allow removal of the feature flag. It would also make the code a little cleaner, since there's not a great way to do conditionals with cfg (see rust-lang/rust#71679).
Opening this as a way of opening the discussion about an issue that I was running into. If you would prefer a different approach, I'm happy to discuss that. Within multi-language environments, such as bazel, cargo isn't always able to drive the build process. However, prost and prost-build provides an amazing foundation of which to build off. The general idea of this commit was to open up prost-build to having tools built off of it, while still preserving previous behavior. Currently, if PROTOC or PROTO_INCLUDE are not set at build-time, then the build fails. This commit introduces feature, runtime-protoc. This hides env! invocations when enabled, allowing compilation, under the assumption that the protoc location will be provided at runtime. This wouldn't be my first preference, but I was prioritizing the build-break if the environment flags were not specified. I would generally have preferred grabbing those with option_env! macros and then trying to gracefully handle the error at runtime protoc has not been provided at build time or runtime similar, since this is already covered by tests. That would allow removal of the feature flag. It would also make the code a little cleaner, since there's not a great way to do conditionals with cfg (see rust-lang/rust#71679).
I tried this code:
I expected to see this compile based on the std::cfg macro docs, instead, this it failed to compile. This was confusing, as I was able to write this, in a slightly less clear way, using cfg attributes. The documentation calls out the links between the two, saying
The syntax given to this macro is the same syntax as the cfg attribute
.Should the docs for std::cfg be updated to state that both branches of the if/else need to be valid regardless of the cfg! condition? Or is this something that would be expected to compile?
Meta
This was tested on 1.42.0, but from compiler explorer, this shows up in all versions since 1.0.0
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: