-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Provide an ergonomic way to check code with all features #1337
Comments
So a couple of things, I am curious if there is a solution that doesn't use mutually exclusive feature flags. This in of it self breaks kinda how cargo handles feature flags as you can tell from the issue you linked. For me it's a bit important to not use make as I am using In the end, if the only feature flag that I need to add beyond default is docker, I think it is fine. But I'm not a big fan of having a huge array of feature flags and combinations which can lead us to missing things sometimes. |
I was thinking about this, it could be fixed by adding support for building new versions of LevelDB in It would allow us to keep features for |
Seems like a good idea. |
Closing this since it hasn't seemed to be an issue. |
Before #1331
make check
was equivalent tocargo check --all --all-features --all-targets
.However, after #1331 the feature pairs
leveldb-plain
/leveldb-cmake
andrdkafka-plain
/rdkafka-cmake
became mutually exclusive. These pairs of mutually exclusive features needed to ensure that all dependencies forleveldb
andrdkafka
are correctly written toCargo.lock
, so that Vector can be built with--freeze
build flag. Cargo doesn't support defining mutually exclusive features yet (see rust-lang/cargo#2980), so the command inmake check
was changed tocargo check --all --all-targets
.It means that
docker
feature is not checked anymore whenmake check
is called, although it is still compiled in CI as part oftest-stable
.One approach is to change
check-code
target in theMakefile
to something likeHowever, this approach doesn't look like very elegant and there might be a better solution. I'd like to hear @LucioFranco's thoughts about this.
The text was updated successfully, but these errors were encountered: