Allow code generation without android SDK/NDK #154
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have the same issue mentioned in #107 (specifically: #107 (comment)).
In short, some of our developers working with the generator are not android developers, and would rather not have to set-up the android SDK/NDK to use djinni, considering those are only needed to build the android examples.
I know nothing about Bazel, but still I decided to try and find a solution to this. I started investigating a way to conditionally trigger the android repo rules for the examples only, when I found this discussion:
bazelbuild/bazel#14260
From there, I understand that the rule should only be applied in case one tries to build a target that requires the android SDK, but apparently that is not the case yet. In the same discussion, I found a suggestion for a workaround, which amounts to only defining the
android_sdk_repository
andandroid_sdk_repository
rules if the environment variables for the paths to the SDK/NDK are set:envoyproxy/envoy-mobile#2039
I implemented the same, with a trivial tweak, which is printing a warning in case the environment variables are not set, to counterbalance the fact that the build failure message for the
android-app
andandroid_sdk_repository
is now less explicit.It seems to work fine, hopefully it's not too hacky and can be useful upstream.