[Openmcl-devel] Questions about binding *target-backend* and *features* - cross-building lx86cl.image=>armcl.image for Termux Linux+Android ARM environments

[lab at thinkum.space]

Hello,

I've begun developing a port for CCL 1.11.5, using the Termux 
termux-packages[1] source repository in a local Docker instance of the 
termux/package-builder[2] Docker image. This is with Debian 10 on an 
amd64 architecture.

After a couple of modifications to some build scripts in the original 
termux-packages source repository[3] and a couple of patches for -- in 
effect -- making something of a union of the build configurations for 
CCL linuxarm and androidarm builds, I've been able to build an armcl 
kernel image launcher for a Termux Linux ARM-in-Android ARM environment. 
This armcl can be run in a Termux[4] environment installed on an Android 
6 platform.

Although I look forward to sharing the changesets, to such effect, 
candidly it does not presently appear to represent an actually usable 
set of changes, at this time.

With the termux-packages + Android NDK toolkit configured towards an 
effect of something like ANDROID_API=21[5] the resulting armcl can be 
run to a point of successfully emitting a message, in an Android 6 
environment, such that seems to indicate that it needs an armcl.image 
rebuild. Presently, I'm trying to figure out how this may be approached 
with CCL i386/x86 i.e lx86cl version 1.11.5 on the same Debian 10 host 
(amd64).


I've noticed that there are the source files 
"ccl:compiler;ARM;arm-arch.lisp" and "ccl:compiler;ARM;arm-backend.lisp" 
available in CCL. One might presume that those files may be of some 
potential use towards binding CCL::*TARGET-BACKEND* in an a 
cross-builder environment.

The arm-arch.lisp file appears to define the ARM package, such that 
would be referenced in the second of those two source files. The source 
file, arm-backend.lisp, appears to define something that I presume could 
be used with #'CCL::FIND-BACKEND if only when the source file is 
evaluated under some specific *features* symbols.


I wonder if there may be any ideal way to bind the appropriate 
*features* symbols and load these source files, then to set 
CCL::*TARGET-BACKEND* for application with CCL::XCOMPILE-CCL and/or 
similar functions? Locally, I'm focusing on the usage case of 
cross-building lx86cl=>armcl

Perhaps it could be overly simple, if there could be any single function 
defined, such that could define the appropriate CCL::*TARGET-BACKEND* 
without rendering the running *features* list into any manner of 
"Unusable by side effect" state, in the main REPL environment, To even 
begin to estimate what would be the appropriate *features* 
configuration, however -- as perhaps, before binding 
CCL::*TARGET-BACKEND* per the definitions provided in those source files 
-- but I would not want to try to guess around, as to what would be the 
ideal, initial *features* configuration, or if there might be any 
recommended approach towards evaluating the source files needed for 
defining the appropriate *target-backend* and any other variables for 
the cross-build.

Towards an effect of perhaps defining such a function, I wonder if it 
may be "The thing to do," pragmatically, to remove symbols such as 
:X86-TARGET :X8632-TARGET and other *-TARGET symbols from *features* and 
to add any corresponding ARM*-* symbols to *features* before evaluating 
those source files? and before calling XLOAD-LEVEL-0 or XCOMPILE-CCL. 
Furthermore, I wonder  if there are not any few more steps that I cannot 
guess, at this time.

Of course, there's CCL::*HOST-BACKEND* as towards determining what 
symbols might collide with features of the CCL::*TARGET-BACKEND* in the 
cross-build.

Perhaps one could lexically shadow the *features* list, subsequently 
removing the features symbols of the *HOST-BACKEND* from the shadowed 
value, and then load each of "ccl:compiler;ARM;arm-arch.lisp" and 
"ccl:compiler;ARM;arm-backend.lisp"?

If that would work out, to an effect of defining the correct 
*TARGET-BACKEND*, is it correct to assume that one should call 
XLOAD-LEVEL-0 next?


However it may be that a usable armcl.image may be built, for this 
configuration, then pursuant of further testing for the armcl build, I 
look forward to sharing the local changesets for adding CCL to 
termux-packages.


TY,

- Sean


[1] https://github.com/termux/termux-packages
[2] https://hub.docker.com/r/termux/package-builder/
[3] mainly towards an effect of -D__ANDROID_API__=21 furthermore using 
the specific armv7a-linux-androideabi21-clang build from the Android NDK 
(of a major version 24) as CC
[4] https://play.google.com/store/apps/details?id=com.termux
[5] In some terms of the AOSP ndk-build infrastructure, such that may 
appear to use a fork of GNU Make in the most, the local build 
configuration represents something analogous to ANDROID_API=21. For some 
API versions later than 21, the builds may not be usable on some Android 
6 platforms.