Comments (15)
Hi @elvisdukaj
The default settings already include:
Android:
api_level: [ANY]
From our understanding the api_level
should be good to represent the binary compatibility, not the actual NDK version (kind of the same as VS with different toolsets, the one affecting the binary is the toolset version, not the IDE version). Have you tried it already?
from conan.
Hi @memsharded, thank you for the quick feedback!
I am aware of the os.api_level
that can affect the ABI, I will open another issue about the os.api_level
as is not working as expected though.
Android API level and Android NDK version unfortunately are not stricly correlated. As an example building a library using android-ndk/r21a
and android-ndk/r21b
using the same os.api_level
(we used 19) leads to a broken build when these settings are mixed.
Even worst is that it's impossible to distinguish between these 2 ndk, they have same compiler version for instance :\
from conan.
About the os api_level is meant to be forward compatible, that means that if I built with api_level=17
this can be used with any api_level
>= 17, but the ABI is not guarantee for lower version.
With the actual implementation instead I need to rebuild all the packages even when moving for instance from API Level 30 to 31 even if there is no need.
I will work on a fix that is setting the api level to the minimum required instead to avoid dupplications.
from conan.
In any case, if you want to add an ndk
version to the default settings, that would be trivial, wouldn't it?
Something like:
Android:
api_level: [ANY]
ndk_version: [ANY]
And from there you can add os.ndk_version=XXX
to your Android profiles and every version will create a distinct binary. Am I missing something here?
from conan.
Hi @elvisdukaj
The default settings already include:
Android: api_level: [ANY]
From our understanding the
api_level
should be good to represent the binary compatibility, not the actual NDK version (kind of the same as VS with different toolsets, the one affecting the binary is the toolset version, not the IDE version). Have you tried it already?
Hi @elvisdukaj
The default settings already include:
Android: api_level: [ANY]
From our understanding the
api_level
should be good to represent the binary compatibility, not the actual NDK version (kind of the same as VS with different toolsets, the one affecting the binary is the toolset version, not the IDE version). Have you tried it already?
I was thinking to add something similar as the sdk_version
in MacOS.
Android:
api_level: [ANY]
ndk_version: [ANY]
Maybe I will propose an MR if that works internally. For making this even nicer I need to change the recipes in of android-ndk
so that this value is automatically set when the android-ndk
tool is required for building.
from conan.
In any case, if you want to add an
ndk
version to the default settings, that would be trivial, wouldn't it?Something like:
Android: api_level: [ANY] ndk_version: [ANY]
And from there you can add
os.ndk_version=XXX
to your Android profiles and every version will create a distinct binary. Am I missing something here?
In any case, if you want to add an
ndk
version to the default settings, that would be trivial, wouldn't it?Something like:
Android: api_level: [ANY] ndk_version: [ANY]
And from there you can add
os.ndk_version=XXX
to your Android profiles and every version will create a distinct binary. Am I missing something here?
No you didn't miss anything, this is exactly how I would like to proceed. I just want to point out that this is not just my special case, but I think it's a missing parameter in the actual settings.
from conan.
The problem is that this forces Android users to define a ndk_version, which would be breaking. At the very least it should be [null, "ANY"]
. But still, if there are no other direct implications in the codebase, probably the recommendation would be to keep it in your own settings_user.yml
, no need to contribute it to the main Conan settings if not necessary mainstream.
I am not so sure that the binary compatibility is so bad in the general case for different NDK versions. Is this something that happens in your case all the time for all the packages using different NDK versions? Or it is more like it fails in some special, particular cases?
from conan.
Android unfortunately is not consistent in keeping ABI compatibility between different ndk, in our internal expirience the ABI compatibility between NDKs was missing, despite the toolchain major and minor build was the same.
I am fine to keep this as internal setting for now, the only downside I see is that I need to fork the android-ndk
recipes so that the correct ndk_version
value is set. This way it will be harder to merge the upstream in future if things change or to contribute to the project for improvement.
from conan.
I wanted to point out that msvc
has the toolset
while iOS
, watchOS
, tvOS
, visionOS
and Macos
have the mandatory sdk_version
that is simlar to the ndk_version
and I found this a miss for Android!
from conan.
I am fine to keep this as internal setting for now, the only downside I see is that I need to fork the android-ndk recipes so that the correct ndk_version value is set.
I am not sure what does it mean. The ndk
version will be a property of the tool_requires
, do you mean when using a tool_requires
? But if you define it as tool_requires
, the version will be already define, it is not that you can define it from the input setting.
from conan.
Essentially in the android-ndk
recipes I need to have a table matching to get the right ndk_version
value based on the version of the recipe.
Something like:
class AndroidNDKConan(ConanFile):
# Even better if this is defined in the YAML file instead of here?
@property
def _ndk_version(self):
version_map = {
"r19c": "19.2",
"r20b": "20.1",
"r21e": "21.2",
"r21d": "21.3",
"r22": "22",
"r22b": "22.1",
# [...]
}
return version_map[self.version]
# [...]
def package_info(self):
# [...]
??? Force self.settings.os.ndk_version = self._ndk_version
# [...]
I don't know really if this is possible at all though 🤔
from conan.
Force self.settings.os.ndk_version = self._ndk_version
No, not possible, see: https://docs.conan.io/2/knowledge/guidelines.html#forbidden-practices
Settings and configuration (conf) are read-only in recipes: The settings and configuration cannot be defined or assigned values in recipes.
from conan.
I see, I guess the best option I have then is to put it inside the profile for now. Thank you for the help!
from conan.
I got feedback from other user about the binary incompatibility from different NDK versions, so:
- I am proposing to the team to add a default
ndk_version
to Android subsetting - It might accept a
null
value, to not break existing users - The incompatibility seems to come from major versions r25, r26, but not from minors a, b. We might want to be able to model both scenarios
from conan.
Thank you for the feedback! That will be awesome already!
from conan.
Related Issues (20)
- [question] How to declutter the test package's source repository after building it? HOT 12
- [feature] Cuda flags HOT 3
- [feature] Consider having `cppstd_flag` tool split to also be able to pass the compiler.cppstd value directly HOT 1
- [bug] Conan create fails in test package step when run against a lockfile
- [question] Env var values from package_info() taken over system env vars HOT 2
- [question] Please help how to use NuGet Libraries with Conan and CMake for Builds. HOT 1
- Error uploading file: conanmanifest.txt, '404 Client Error: Not Found for url: https://artifactory.com/artifactory/api/conan/conan-test/v2/conans/xxx/revisions/b9c4826ad9445ea5257f6432b5a019dd/files/conanmanifest.txt[bug] HOT 3
- [question] Confusion around python_requires using minor_mode HOT 6
- [bug] incorrect paths generated by pkgconfigdeps.py when using --deployer option HOT 1
- [question] Filtering options for package to get path to local cache HOT 4
- [bug] `conan list` filtering option asks users to use scope patterns when those don't work in that context HOT 2
- [question] Set cmake_find_mode for all deps in CMakeDeps [conan 2] HOT 2
- [feature] Option to suppress generation of script files HOT 2
- [bug] Initial setup for Conan test suite is not automated or documented HOT 1
- [question] disable package revisions HOT 3
- [bug] Pulseaudio issue while installing SDL2 HOT 7
- [bug] `conan source` does not actually get `global.conf`'s `core.` confs
- [question] Install a binary package without matching the compiler version HOT 1
- [question] preset name != profile name HOT 2
- [question] Include jinja profile template into another
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from conan.