Skip to content
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

add conan.tools.android.android_abi() #12873

Merged
merged 5 commits into from
Feb 14, 2023

Conversation

SpaceIm
Copy link
Contributor

@SpaceIm SpaceIm commented Jan 9, 2023

Changelog: Feature: Add conan.tools.android.android_abi() function to return the Android standard ABI name based on Conan.
Docs: conan-io/docs#2975

closes #12814

  • Refer to the issue that supports this Pull Request.
  • If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
  • I've read the Contributing guide.
  • I've followed the PEP8 style guides for Python code.
  • I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.

@AbrilRBS
Copy link
Member

I think this would be cool to have added in the docs :)

@SpaceIm
Copy link
Contributor Author

SpaceIm commented Jan 16, 2023

Sure, but when I know it has a chance to be merged. I don't want to work on documentation if this feature is rejected.

Copy link
Member

@memsharded memsharded left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is looking good and could be merged, but I'd prefer to avoid a silent fallback to another context, better raise if profile build or target not correctly defined.

if context not in ["host", "build", "target"]:
raise ConanException("context argument must be either 'host', 'build' or 'target'")

settings = getattr(conanfile, f"settings_{context}", conanfile.settings)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are providing the context, then falling back to the host settings doesn't look great, it should be explicit.
I ask you for the "build" context, you return the build context or fail. If this is being used in a cross-build scenario with 1 profile only, then it is allowed (should) fail.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @memsharded, this is something that should not fall back if missing. What usecase did you have in mind for allowing the fallback?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I had 1 profile in mind, to not raise even if it makes little sense to call this function with 1 profile. Also I didn't want to be too strict with settings_target since it depends on context in which a recipe is called, I'm not sure of the consequences in recipes.

So what would you want? Raise ConanException if settings_{context} is not an attribute of conanfile? Even for settings_host?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

settings_host obviously doesn't exist, so it would be necessary to do the right thing, and do an if context == "host" or a dict mapping or something like that. But yes, it is better to raise if not defined, and this function should only be used with 2 profiles. It is typically better to be initially restrictive and raise, then letting some behavior slip, and then users depending on this behavior (for 1 profile) will complain later if this breaks for some reason that we need to force exclusively for 2 profiles (already happened a few times)

@memsharded memsharded added this to the 1.58 milestone Jan 26, 2023
@memsharded memsharded requested a review from AbrilRBS January 26, 2023 08:46
Copy link
Member

@AbrilRBS AbrilRBS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking the time to implement this. I only have a few minor comments before we can merge :)

def test_tools_android_abi():
settings_linux = MockSettings({"os": "Linux", "arch": "foo"})

for (arch, expected) in [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is usually better to be done with a @parametrized decorator in the function itself, so failures are easier to debug, but I'm ok with this either way :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember to have written tests with @pytest.mark.parametrize, then move to this implementation but I don't remember why. I can change back to parametrize.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No big deal, if it works with parametrize easily, then do it, but don't waste time if you hit some issue.

if context not in ["host", "build", "target"]:
raise ConanException("context argument must be either 'host', 'build' or 'target'")

settings = getattr(conanfile, f"settings_{context}", conanfile.settings)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @memsharded, this is something that should not fall back if missing. What usecase did you have in mind for allowing the fallback?

"armv7": "armeabi-v7a",
"armv7hf": "armeabi-v7a",
"armv8": "arm64-v8a",
}.get(arch, arch)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the old code, android_abi would have been None for missing archs. The second parameter here changes that bahaviour, which might be more correct (No idea), but we should make sure it does not have any unintended side-effects

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well there are 2 old codes, inconsistent:

  • legacy toos.to_android_abi() => it fallbacks to str(conanfile.settings.arch)
  • CMakeToolchain => fallbacks to None

So a decision has to be made for this new one, as you wish, I've not a strong opinion on this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think falling back to the arch input instead of None might be better, for cases where the users extend settings.yml with their own architectures, if they map directly to android ones, then this will work. So I am fine with this as-is.

Copy link
Member

@AbrilRBS AbrilRBS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! (Sorry about the delay!)
Please don't forget about adding docs for this, will merge once linked so it's easier to write the changelog!

@memsharded
Copy link
Member

We are releasing 1.58 asap, this would be missing settings raising when not defined, moving to 1.59

@memsharded memsharded modified the milestones: 1.58, 1.59 Jan 30, 2023
Copy link
Member

@memsharded memsharded left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently this is not that needed in ConanCenter, but I am fine with moving this forward for 1.59, if the settings fallback to host is removed.

@memsharded memsharded merged commit ec2aa42 into conan-io:develop Feb 14, 2023
@SpaceIm SpaceIm deleted the feat/android_abi branch February 14, 2023 22:58
@SpaceIm
Copy link
Contributor Author

SpaceIm commented Feb 14, 2023

Thanks for the final polishing. It will be useful in android-ndk recipe (but not anymore in opencv recipe, I have a PR removing its usage).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[feature] Port conans.tools.to_android_abi to conan v2 tools
4 participants