Document Viewer: Fix build.

Thanks for your patch!

However, I'm wondering whether this is really the best solution. I added the ./init.sh script because I want to add more patches and submodules in the future. For example, the djvulibre source code is still directly embedded into the repository. For future versions it would be desirable to include djvulibre as a submodule and apply all necessary changes to the source via patches. Also, I'm wondering whether submodules=yes will pull in submodules recursively. (The submodule mupdf depends on further submodules.)

Would it be possible to somehow execute init.sh directly instead of copying everything from init.sh into the prebuild option here?

Submodules in fdroid work recursively, so this wont be a problem. Patches have to be added within our prevuild as well, but had also to look at them if we'd just use the init script. We have some apps using such scripts, but I'd rather advise against them, especially if they run downloads (again, this is done in other apps, too) or scm/vcs commands. The reasoning would be that you want to seperate "getting the source" and "building the app". E.g. we provide source tarballs, which most likely don't reproduce the vcs state, but are a plain file dump only. Git operations will fail on them..

However, this is my point of view, but since this is not my field of expertise, I'd like to talk to other fdroid staffers. Maybe @mvdan can shine some light here?

Yup, don't worry about submodules. The way you do them in init.sh is weird though, you can just add --recursive to git submodule update --init.

Regarding scripts being run in prebuild - as Boris said, fine as long as they don't build anything nor download anything. Yours seems to be fine in that aspect.

Doing the submodules again isn't harmful, so I would suggest leaving submodules=yes in for reference.

Thanks for pointing me to the --recursive option (future versions of document-viewer will use it) 👍

The next build should use init.sh, see 7c6016ad.