-
Notifications
You must be signed in to change notification settings - Fork 50
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
Improving examples build configs and documentation. #155
Changes from all commits
ab46995
fb63bbc
0e5bd48
f2143f8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -53,7 +53,7 @@ android_library( | |
srcs = glob(["handwritten-src/java/com/dropbox/textsort/*.java"]), | ||
custom_package = "com.dropbox.textsort", | ||
manifest = "android/app/src/main/AndroidManifest.xml", | ||
resource_files = glob(["android/app/src/main/res/**"]), | ||
resource_files = glob(["android/app/src/main/res/**"], exclude=["android/app/src/main/res/.DS_Store"]), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this cause builds to fail? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah, basically if Mac Os adds these .DS_Store files, then the glob is picking them up and failing the build. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is strange. Do you mean Macos will put files in a source tree that cause bazel based projects to fail? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Exactly |
||
deps = [":textsort-java",], | ||
) | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason we require these versions? I don't remember the example app uses any new features that's only available in these versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the sdk version is hardcoded here:
djinni/bzl/android_configure.bzl
Line 27 in c7b0a39
The NDK versions here:
https://github.com/Snapchat/djinni/blob/c7b0a3978ebe34cc7b5e8323c0ecab5b75017ba7/bzl/android_configure.bzl#L37C17-L37C17
21.4.7075529 specifically is the latest update to that version.
A later NDK should be backwards compatible, however the bazel version specified to build this project only supports up to version 21, and warns (fiercely) that errors can be introduced by using a later NDK version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just did a quick test and find that android example build still works if I complete remove the hard coded versions
I think we probably should just remove these as we don't really use anything that requires a specific version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just think we should avoid putting hard coded versions in here because they needlessly prevent people from building the code with whatever they already have in their system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, that is a better solution.
Let me try that.