Open dylanmccall opened 2 years ago
If a build system uses just the first term of CC
, then it is going to be missing some other (important) flags set by p4a build system as well. Maybe the preferred solution here is to patch the source code of the module to allow it to use the entire CC
. It is not uncommon, but many build scripts just don't care about/support proper cross-compilation.
I recently created a recipe to build python-zstandard, a Python module with a native component. I encountered an issue where the build script was attempting to run
ccache
on its own with some compiler flags, similar to #1398. This happened because:ccache
is available (and not disabled), it is prepended toCC
: https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/archs.py#L158-L195. This results in something likeCC="ccache gcc"
.CC
is the compiler, and uses that on its own, adding a new set of parameters: https://github.com/indygreg/python-zstandard/blob/main/make_cffi.py#L31-L66. This is frustrating, but not an uncommon assumption.Since I have the luxury of a project that only needs to build one way, this is how I worked around it on my end:
https://github.com/endlessm/kolibri-installer-android/commit/7e4eab72da2e888d59fc058f9c36ad636a64e3b8
So, instead of patching the module or changing the environment variable, I told P4A to stop thinking about ccache, and enabled it on the host by setting
PATH="/usr/lib/ccache:$PATH"
. This works because/usr/lib/ccache
is a directory full of look-alikes for different compilers, all of which point toccache
. It is one of two recommended ways to use ccache: https://manpages.ubuntu.com/manpages/jammy/man1/ccache.1.html.My suggestion here is that the current approach is problematic, and perhaps dealing with ccache on the host instead of in P4A would be a good practice to recommend in general.