-
Notifications
You must be signed in to change notification settings - Fork 305
Fix android compilation #829
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
base: master
Are you sure you want to change the base?
Conversation
See for reference microsoft/vcpkg#44940
This seems based on bogus assumptions: microsoft/vcpkg#44940 (comment)
This is true if So it's true that the value is not reliable enough. Note that this is only for people using the recommended cmake toolchain file provided by the NDK. In VLC for example we relied on CMake until recently and still do on VLC 3.0 (stable branch). Neither TLDR: I think both values need to be checked. The PR in its current state will break the VLC 3.0 build. |
I'm not expert here, I'm just forwarding what we've done in VCPKG. |
This is one of the downside of VCPKG, they make patch locally and don't send them upstream for review. It's good that you submit it here @abique. That patch might be enough for VCPKG that may force the use of the For the more general case I think the |
I authored the original vcpkg patch, and I came here for upstreaming. I'm surprised about the negative judgements in the comments ("bogus assumptions", "don't send upstream") while confirming at the same time that this judgement is wrong ("documentation", this PR). I don't claim to know much about flac, but I do have some familarity with vcpkg and most target platforms it supports. The original patch was intentionally minimal, tailored for vcpkg. When authoring the patch, I did research the changes which lead to the build problem, and I did assume that there was testing with a different CMake toolchain. So I did expect that "upstreaming" would mean adjustments. So how to continue from here in a positive way? |
There is one ugly thing about |
I verified that when using
Testing without and setting
That's with CMake 3.22.1 on Ubuntu. But there's a plot twist. If I change the
So a user should either use
That line (119) is used in case the user sets With all that being, to properly support builds with and without You could use something like this instead:
In both usage it will have the proper Android target value. |
Actually it's not entirely clean as it should only be done for Android targets, Here are 2 ways to do it depending if you want to check ANDROID_NATIVE_API_LEVEL or CMAKE_SYSTEM_VERSION (I have no preference):
Or simply switch the test to
|
I'm creating another PR. |
See for reference microsoft/vcpkg#44940