Prepending CC with ccache confuses some build systems

[dylanmccall]

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:

• We have ccache installed on the host.
• In python-for-android, if ccache is available (and not disabled), it is prepended to CC: https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/archs.py#L158-L195. This results in something like CC="ccache gcc".
• In python-zstandard's build system, it assumes the first item in 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 to ccache. 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.

[mzakharo]

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.