Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

Support multiple architectures #32

Closed
mansourmoufid opened this issue Dec 27, 2021 · 3 comments
Closed

Support multiple architectures #32

mansourmoufid opened this issue Dec 27, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@mansourmoufid
Copy link
Contributor

mansourmoufid commented Dec 27, 2021

Hello,

At the moment, briefcase installs all Python packages into a single directory (app_packages). This works great for pure-Python packages. It also works for modules compiled for a single architecture.

It would be nice to support multiple architectures (e.g. armeabi-v7a and arm64-v8a on Android). I can think of two possible solutions. First, architecture-specific package directories. Second, architecture-specific filename extensions. Which is better?

Edit: I forgot to mention... The first requires changes to briefcase and briefcase-android-gradle-template; the second requires changes to briefcase and Python-Android-support, so I opened the issue here for discussion.

Solution 1

TODO

Solution 2

The extension of Python modules is set by the configure script according to the variable SOABI:

# ABI version string for Python extension modules.  This appears between the
# periods in shared library file names, e.g. foo.<SOABI>.so.  It is calculated
# from the following attributes which affect the ABI of this Python build (in
# this order):
#
# * The Python implementation (always 'cpython-' for us)
# * The major and minor version numbers
# * --with-pydebug (adds a 'd')
#
# Thus for example, Python 3.2 built with wide unicode, pydebug, and pymalloc,
# would get a shared library ABI version tag of 'cpython-32dmu' and shared
# libraries would be named 'foo.cpython-32dmu.so'.
#
# In Python 3.2 and older, --with-wide-unicode added a 'u' flag.
# In Python 3.7 and older, --with-pymalloc added a 'm' flag.
AC_SUBST(SOABI)
AC_MSG_CHECKING(ABIFLAGS)
AC_MSG_RESULT($ABIFLAGS)
AC_MSG_CHECKING(SOABI)
SOABI='cpython-'`echo $VERSION | tr -d .`${ABIFLAGS}${PLATFORM_TRIPLET:+-$PLATFORM_TRIPLET}
AC_MSG_RESULT($SOABI)

This value is then accessible at run-time with sysconfig.get_config_var('EXT_SUFFIX').

The distutils module (and setuptools) uses EXT_SUFFIX when compiling modules (the build_ext command):

    def get_ext_filename(self, ext_name):
        r"""Convert the name of an extension (eg. "foo.bar") into the name
        of the file from which it will be loaded (eg. "foo/bar.so", or
        "foo\bar.pyd").
        """
        from distutils.sysconfig import get_config_var
        ext_path = ext_name.split('.')
        ext_suffix = get_config_var('EXT_SUFFIX')
        return os.path.join(*ext_path) + ext_suffix

So if we set SOABI during configure to the Android ABI, say "arm64-v8a", then EXT_SUFFIX is ".arm64-v8a.so". Then distutils and setuptools can be patched to read EXT_SUFFIX from an environment variable rather than the host Python's sysconfig.

Then, hopefully, briefcase would just work with multiple architectures.

@mansourmoufid mansourmoufid added the enhancement New feature or request label Dec 27, 2021
@paulproteus
Copy link
Contributor

Hi @eliteraspberries !

I think that the directories approach is the better one. The reason is that https://developer.android.com/ndk/guides/abis#native-code-in-app-packages indicates that Android and the Play Store have some tooling that assumes a directory-based layout.

Let me know what you think. I haven't done any substantial work on Python-Android-support in a year-ish, so my understanding may be inaccurate in pieces.

@mansourmoufid
Copy link
Contributor Author

Ah yes, that does make more sense. Now that I read more of the source, it's also the simpler solution. It might even be possible to implement this with only changes to briefcase, and maybe a line or two in briefcase-android-gradle-template.

@mansourmoufid
Copy link
Contributor Author

OK solution 1 works. See: beeware/briefcase#647 (comment)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants