I have my own custom toolchain for writing Android applications and I’m happy sideloading them onto my own devices. However, someone recently suggested that I might distribute them via F-Droid, so I promised them I would investigate.
My impression is that the normal build process for F-Droid apps uses fairly standard tools. My build process involves some Python (2 not 3) modules and the openssl command line tool. How difficult would it be to accommodate a custom build process and where would I start investigating how to do it? Would it even be a desirable thing to have?
It’s all public, so no secret handshakes are required.
I was talking in general terms, but here’s an application that I could consider sharing with the wider world via F-Droid - as opposed to making everyone build it themselves.
I had a look at your code and built Weather Forecast locally. While it is certainly a bit more work for us than building an app with Gradle, it is not a problem.
The only issue I see right now is that your build.py script also signs the APK. F-Droid already has a signing process that comes after the building so we need a way to build unsigned APKs.
You should open an RFP for the apps you want us to package and we can move forward from here
You will also need to add tags to your Git repository. This is how F-Droid detects that a new release is avaible.
Oh and if you could specify in your README which version/commit of Duck is needed to build the app, that would be great. (We often have issues with custom SDKs like Flutter because we try to build an app with a recent version of the SDK but it was written for an older version.)
Thanks. I have thought about the issue of declaring or embedded the toolchain version in the built application before, but not thought much about how to declare it in the sources. Perhaps it could also be included in the build script.
There’s a feature in the build system that lets you include the sources of the application as a resource in the APK, and this uses the version control system’s own command to create an archive (currently only for Mercurial). It might not be useful in this situation but I thought it might be interesting for people to know about it.
I’ll have to search for those. I’m not really interested in writing BASIC apps myself but it’s always interesting to see other alternative-language solutions.
I’ve updated DUCK’s build system to allow packages to be built without signing. I also wrote a setup.py file to make it easier to install the compiler and its support modules. The Weather Forecast app now includes information in its README.md file about the recommended version combination used to build it, and I tagged both repositories.
I’ll take a look at the contribution guide again to see what else I need to do, then I’ll open an RFP.
Do you have an idea how I might add support for my toolchain to F-Droid? I have reached the point with the fdroiddata repository where I can describe my app but I think I will need to do something special with the Build field to actually build it with the fdroid tool.
I adapted your recipe (thanks again!) and found some things I had missed in my build system, so I spent a bit of time working on that.
One thing that might be a problem is that the toolchain caches generated images in the build user’s $HOME/.cache/DUCK directory, so you might want to delete that if you built my package on your own machine. I have now disabled the icon cache for the Weather Forecast app to prevent files from being left behind in unexpected places.
The cache is not really a problem because we use a new fresh virtual machine before building each app.
(As for my local dev computer, I already have a ton of stuff in .cache so this won’t make a big difference.)
I’m guessing that I still need to open an RFP.