This might be a bit of an unusual query.
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?
Is the app secret? Share a repo link and we can take a look…
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.
The toolchain is available from this repository.
If this custom toolchain is all free software and your app can be built on a Debian 8 system, it’s welcome.
Can’t say how difficult it will be to include, but we have some very unusual apps, e.g. written in BASIC.
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
Thanks for taking a look at the build script and going to the trouble of building the app. I will look into making the signing step optional.
If there’s anything else you can think of that I might want to change then feel free to let me know.
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’m not really interested in writing BASIC apps myself but it’s always interesting to see other alternative-language solutions.
I meant this one: https://f-droid.org/packages/com.rfo.basic/
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.
Thanks! I tried running the updated
build.py with F-Droid build tools and it works fine
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
Here is the build recipe I used to test your toolchain: https://gitlab.com/Rudloff/fdroiddata/commit/0c431fa54b220b80043155c8bf70467dfc6c0c17
You can use it as a basis. The trick is to add DUCK as a srclib so it can be imported before the build.
Thanks! I’ll try this later today then create a merge request. This is all a lot easier than I expected.
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.
I’m now trying to do a merge request.
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.)
Thanks for helping me to merge my app metadata. I’m guessing that I still need to open an RFP.
The RFP is mainly used to ask contributors to write metadata for the app.
Since you submitted the metadata directly, it is not really needed.
OK. Thanks for the explanation.