[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU-hosted F-Droid repository for Android applications written in GF
J. R. Haigh
Re: GNU-hosted F-Droid repository for Android applications written in GForth?
Mon, 3 Aug 2020 15:09:27 +0100
Hi Bernd, all,
At 2020-08-03Mon13:40:52+02, Bernd Paysan sent:
> Am Montag, 3. August 2020, 01:34:32 CEST schrieb J. R. Haigh:
> > […] Please could you consider targetting F-Droid?
> The problem is that F-Droid wants to build the app from source, and, as far
> as I can see, F-Droid assumes that your app is a normal Java Android app,
> with a ant or gradle build. We don't do that. Gforth on Android is a
> (pretty contrived) make build, because what we build is a native C library,
> and Forth images, and have lots of interdependencies, need a running Gforth
> on the host, a modified version of swig for generating the C bindings from
> Forth, and whatnot. Finally, we package that, including the dependency
> libraries, which are also build the make build system, and then, we run
> gradle on a small Java wrapper, which just is a replacement for the
> NativeActivity, which is too buggy.
I see. And they're not going to want to do the work of getting a working recipe
going for GForth Android applications while there's a very small number of such
applications. However, neither are most potential Free Software developers
going to get to know about programming Android applications using GForth if
they're not in some repository, and so the number will stay small. There's a
Catch-22 here. :-/
> I have no idea how to get that build process into F-Droid.
Okay, well how about the GForth project hosts a separate F-Droid repository,
including only libre Android applications written in GForth? This should help
to break the Catch-22 situation.
> > […] Please could you provide a demonstration application that I can use as
> > a starting point to develop Android applications written in GForth?
> net2o is such an example.
Oh good! :-)
> The important part is AndroidManifest/apps, here, you can declare which Forth
> source you can provide as starting point.
> You need a makefile with extra-install: as additional target (that installs
> the stuff you need on Android). The makefile can build additional libraries
> and whatever other thing you need, just like Gforth's makefile.
> I should add instructions how to build,
Could you publish these details as an appendix to the GForth manual?
> but essentially, it is running BUILD-FROM-SCRATCH in gforth/arch/arm/android.
> This assumes you have a working Android SDK build environment with gradle,
> including signing key. The BUILD-FROM-SCRATCH also shows how you integrate
> your own app similar to net2o.
Why is Gradle required if this is not a Gradle build? Why is the Android SDK
required if this is an NDK build? Could dependency on Gradle or the Android SDK
Also, when I last did some Android Java programming in 2012, I remember
that the Java package-name was a pain, and devised a mechanism for specifying
the package-name in a single place rather than scattered throughout the source
tree. Is there an easy way to centrally-specify the package-name in your GForth
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
Yes indeed, I've come to realise this over the years, but I've also come to
realise that if you have to do it yourself then you have to start with
something very much more minimalist than what's popular. I've no hope of
getting things right using Haskell/GHC, for example, and hence I'm switching to
GForth as my favourite language, having become aware of the syntactic
simplicity of postfix and concatenative programming. Likewise, although I'll
likely continue using GNU+Linux and Android for many years, for some projects
I'm already considering Forth-based bare-metal systems instead of using even a
realtime operating system!
> net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
I had a read of that – that in itself is very interesting!!! :-D :-D :-D
Wealth doesn't bring happiness, but poverty brings sadness.
Sent from Debian with Claws Mail, using email subaddressing as an alternative
to error-prone heuristical spam filtering.