Hi Bernd, all,
What do you think about a separate F-Droid repository? (See:
https://F-Droid.org/en/docs/Setup_an_F-Droid_App_Repo )
At 2020-08-03Mon16:15:53+02, Bernd Paysan sent:
> Am Montag, 3. August 2020, 16:09:27 CEST schrieb J. R. Haigh:
> > 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 be removed?
> No, in the end, you need to compile this some hundred lines long Java
> program, and package the whole thing as apk or app bundle. And that's what
> Gradle/SDK does.
Okay. At least there are freedom-reviewed packages of the Android SDK
available. Debian has packaged most of it since about 2017
(https://bits.debian.org/2017/03/build-android-apps-with-debian.html ), and
there also seem to be some android-* packages in GNU Guix
(http://guix.gnu.org/en/packages/A ), but no ‘android-sdk’ as of yet.
> > […] Is there an easy way to centrally-specify the package-name in your
> > GForth build method?
> I think the mess goes down a bit, but maybe needs a bit more work to make it
> easier.
Right. The idea is to make it easier to fork without forks conflicting with
each other. If I get going with programming Android applications in GForth then
I'll have a go centralising the package-name again, as I did 8 years ago.
Iirc., I think that I might have gone as far as adding the settings file
containing the package-name to the Git exclusion list such that the
package-name is not even in the repository, and other developers therefore have
to set the package-name before building. And as the exclusion list was
committed, this policy would perpetuate unless explicitly changed. My
implementation was clunky, though; I think that its Ant build preprocessor
script constructed a temporary copy of the source tree with the package-name
inserted in the various places.
Best regards,
James.
--
Wealth doesn't bring happiness, but poverty brings sadness.
https://wiki.FSFE.org/Fellows/JRHaigh
Sent from Debian with Claws Mail, using email subaddressing as an alternative
to error-prone heuristical spam filtering.
