[Openmcl-devel] Some progress in porting to CCL to Termux - Tentative -DTERMUX_ANDROID patch for CCL 1.11.5 C source files

[Sean Champ]

Hello,

If it may be of any use to publish any manner of a progress report for 
contributing a build.sh for CCL support in termux-packages[1], candidly 
I believe I've reached the point where I'd like to take a look at using 
CastXML[2] potentially as something of an alternative to FFIGEN in CCL.

In a more literal way, it seems that I should like to have initialized 
the structure slot being accessed by  
(ccl::backend-target-foreign-type-data ccl::*androidarm-backend*). For 
this, it may seem that is should need an application of CCL FFIGEN, such 
that the CCL FFIGEN would be applied onto a set of header files provided 
in the Android NDK. From there, it may not be any less complex to 
configure the build accordingly, albeit.

If there may be any single set of header files in the NDK, specifically 
for an Android NDK platform version 21, perhaps those might be the best 
to focus on -- as in an interest of portability for individual Android 
devices, on install, pursuant of certain changes in LLVM and the NDK. In 
some NDK API versions later than 21, the toolchain may not be able to 
produce binaries that could be used on some Android 6 devices, afaict. 
Using version 21 it seems to work out -- at least, so far as one may 
estimate after some local builds with termux-packages, for an Android 
32-bit ARM device (Android 6) and that API version.

If anyone may be able to ascertain how to usefully reproduce such a 
build configuration in any arbitrary build environment: The matter of a 
"version 21" focus, in application of the Android NDK, perhaps it may 
entail using a somewhat specific clang compiler and when applicable, a 
corresponding clang++ -- typically versioned for API version 21 and 
named for the target build architecture, generally -- under the NDK, and 
a separate set of compiler tools (LLVM NM, AR, LDD, etc) with no API 
version number, all generally under a pathname for the build host 
architecture, such as toolchains/llvm/prebuilt/linux-x86_64/bin/ in the 
Android NDK.

 From a manner of a toolchains perspective, I'm fairly certain that 
Google's AOSP must have applied some specific build configurations -- 
certainly, with CMake -- for LLVM, such that there are a variety of 
individual clang and clang++ binaries, and some fewer NM, AR, LLD... 
binaries, all seemingly built for individual target architectures, and 
all bundled under some common pathnames in the NDK. It may not be a 
well-documented feature, albeit.

The preprocessor declaration -D__ANDROID_API__=21 might also be of some 
use in the "NDK API version 21" focus, insofar as for concerning any 
content of the NDK header files, in some ways beyond any applications of 
the NDK's ndk-build fork of GNU Make, or NDK's CMake, or NDK's Gradle 
add-ons.

Insofar as towards a question, What header files to use? for producing 
the *.ffi and *.cdb files for CCL, on any architecture under an Android 
NDK toolkit -- assuming any manner of a compatibility for the GCC parts 
of FFIGEN and, respectively, the characteristics of the target and host 
architectures, and the header files under the NDK -- candidly I'm not 
entirely certain if that may entail any well documented set of features 
of the NDK, either, or for GCC. Personally, I propose to address this 
with a manner of iterative builds and local hacks, thus.

In consideration towards taking a look at CastXML, perhaps towards 
developing an alternative to FFIGEN in CCL, CastXML itself uses LLVM.

Insofar as for applications with the Android NDK, perhaps CastXML may be 
built for such applications, in some alignment with the LLVM bundle in 
the NDK. Albeit, I'm not entirely certain of how the API-version focus 
could be maintained, at that, without making a separate CastXML build 
for every single possible clang. Perhaps there may be any more central 
approach that could be developed, in any review of AOSP's LLVM-build 
tooling, for using CastXML for arbitrary target architectures under the 
NDK.

For toolchains outside of the NDK, perhaps it could be a lot simpler 
there, for producing any FFIGEN-like hacks, subsequently.

In the interests of portability and manageability, personally, I'll try 
to make a focus for developing a CastXML port for pkgsrc-wip under the 
pkgsrc ports system[5] and using the single LLVM build configuration 
(with some local updates, perhaps) under the pkgsrc main ports tree i.e 
lang/llvm.

 From there, if any of this tool-glue works out, perhaps a compleat ccl 
port for pkgsrc could be forthcoming, anyhow in parallel - once either 
FFIGEN4 and/or CastXML can be used for rebuilding the interface 
repository for CCL FFI.

Although I've developed something of a working binaries port for CCL 
support for pkgsrc-wip, candidly, I'm wary of releasing it until I'm 
certain it can be used to an effect of rebuilding itself. The "fetch and 
install the binaries" part, itself, may seem to have been quite trivial, 
focusing on CCL 11.

Candidly, I would not want to be too liberal in proposing any 
development with regards to FFIGEN.


In albeit what may be a trivial idea, perhaps CastXML may be used as 
something like a clang/LLVM front-end in a usage case, generally, of 
preprocessing the NDK header files. The output of CastXML could be used 
together with any XML processing system such as in libxml2 or otherwise, 
for traversing the generally C++ oriented XML output from CastXML.

Perhaps this could be of some use, maybe together with SWIG, too. One 
could endeavor to reuse the generalized interface model, if not the 
exact syntax developed in SWIG -- pursuant towards producing something 
that could be used like FFIGEN in CCL. Perhaps the result could be of 
some use in other FFI systems, too.

Of course, in so many existing works, there's also the GNOME/GTK Object 
Introspection system. I believe it's been used fairly extensively, in 
Vala language tools.

I'm afraid there's nothing more practical to share, at this time, beside 
a set of scarcely tested local patches.


Inasmuch, attached: A fairly trivial, in all ways tentative patch for 
adding a TERMUX_ANDROID declaration for building CCL under Termux. The 
patch is for CCL c source files. I'm not at all certain if it may be of 
any use outside of the Termux builds. [Indemnification Clause Here]

This patch may not be particularly architecture-specific, but the 
applications of the TERMUX_ANDRIOD decl. may not be practically visible 
outside of Android builds.

Insofar as for making a special sub-set of "Android Builds," vis a vis 
TERMUX_ANDROID, I believe it may at least be a useful contrivance -- 
such as in considering that any Termux Debian package builds would 
typically be installed under Termux, for any sense of usability, once 
the Termux apk is installed. Moreover, the Termux deb builds, 
themselves, do not directly use the NDK's ndk-build or CMake, or the 
Android SDK's Gradle. As such, the builds produced for Termux may be 
by-in-large divergent to any builds produced directly with the NDK/SDK 
tools, divergent in a manner of a model of systems configurations.


I've been able to use this patch in producing a working armcl binary 
under Termux, using the NDK distribution in the Termux docker image. The 
resulting armcl can run on an Android arm device. It can run so far as 
that it seems to indicate that it needs a rebuilt armcl.image - thus, 
the focus about FFIEGN, pursuant towards testing the patched armcl.


Of course, before addressing any hacks towards CastXML, I'll take a look 
at building CCL FFIGEN under Termux and/or under pkgsrc - probably 
starting with pkgsrc, at that, shortly.


-- Sean



[1] https://github.com/termux/termux-packages
[2] https://github.com/CastXML/CastXML
[3] http://xmlsoft.org/
[4] http://www.swig.org/
[5] https://www.pkgsrc.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-ccl-1.11.5-termux-android-v1.diff
Type: text/x-diff
Size: 2093 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20191014/55f34fe5/attachment.bin>