Workflow for debugging the manifest file

[wshaos at posteo.net]

So `flatpak-builder --run=... .flatpak-build/build/MODULE-NAME` would 
drop me into the filesystem at the point where the last flatpak-builder 
execution had failed, right? That is useful for inspecting to understand 
why a build failed. That wasn't quite what I was looking for though. The 
section of the manifest I was having trouble with was this:

   build-commands:
   - bash ./build.sh -bin ${FLATPAK_DEST}/bin -j$FLATPAK_BUILDER_N_JOBS
   post-install:
   - install -Dm644 de.klayout.KLayout.appdata.xml 
${FLATPAK_DEST}/share/appdata/${FLATPAK_ID}.appdata.xml
   - install -Dm644 etc/klayout.desktop 
${FLATPAK_DEST}/share/applications/${FLATPAK_ID}.desktop
   - install -Dm644 etc/logo.png 
${FLATPAK_DEST}/share/icons/hicolor/512x512/apps/${FLATPAK_ID}.png
   - desktop-file-edit --set-icon=${FLATPAK_ID} 
/app/share/applications/${FLATPAK_ID}.desktop

(Complete file is 
https://github.com/willsALMANJ/flathub/blob/361e7a114a74653c501154b88ed68811e5ba32ba/de.klayout.KLayout.appdata.xml).

The build.sh script is the part that does all the compiling and takes a 
long time. The post-install commands were the parts I was having trouble 
getting formatted properly.

A few things I have realized that I could do to avoid the long compile 
step:

1. Someone emailed me outside of the list that I should try --ccache. I 
did that and it worked! Running flatpak-builder after modifying one of 
the post-install steps took only about a minute instead of an hour after 
using --ccache. So I think this is the best solution when it works. It 
might still be useful to know of other options for cases where ccache 
can not be used.
2. I could use `flatpak-builder --run=... 
.flatpak-build/build/MODULE-NAME` and just enter each post-install step 
by hand to see if it works. I don't think this would have completely 
solved my problem because flatpak-builder complained about some 
formatting issues with the affected files (like the icon file name not 
matching the FLATPAK_ID string) and just running the post-install 
commands would not generate these messages.
3. I could have moved all the post-install steps in front of build.sh 
because, in my case, none of them actually depended on the compiled 
output. They were just moving the metadata files from the source 
directory to the right install locations. Still I do not think that this 
would have generated the flatpak-builder warnings about the formatting 
of the .desktop file until after build.sh did its long compile.

I wonder if there are other options? I haven't tested this but perhaps I 
could edit the manifest to replace the usual source tarball with a "dir" 
type source pointing to .flatpak-build/build/MODULE-NAME (possibly I 
would need to copy it to another location outside of the flatpak-builder 
cache) and comment out the build.sh build-command. Then the next build 
would start at the point where the previous build stopped and run the 
post-install commands.

On 16.04.2020 17:43, re:fi.64 wrote:
> Afaik the reason for this in particular is because the module isn't
> cached until after the post-install steps. Note that you can always
> `flatpak-builder --run...` into .flatpak-builder/build/MODULE-NAME to
> play around with the previously built version instead of having to
> build a new one for every little test.
> 
> On Thu, Apr 16, 2020, 9:50 AM <wshaos at posteo.net> wrote:
> 
>> I understand that flatpak caches each module in the manifest. So if
>> a
>> module builds correctly the first time and you don't change it, the
>> 
>> previous build will get reused when you build the flatpak again.
>> Recently I was trying to build a flatpak for a project that takes
>> about
>> an hour to compile on my system. I was having trouble getting the
>> post-install steps correct after the main compile (just copying /
>> editing some text files). Each time I changed a post-install item,
>> flatpak would go through the full one hour compile again. Is there
>> any
>> way to get flatpak to reuse the output from a previous attempt to
>> build
>> a module even when the previous build of that module exited with
>> non-zero status? I understand why you would want to have a
>> complete,
>> clean build of the module for the final flatpak, but for debugging
>> it
>> would be nice to have a way to reuse all the compiled binaries
>> while
>> iterating on the build-commands and post-install entries.
>> _______________________________________________
>> Flatpak mailing list
>> Flatpak at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/flatpak [1]
> 
> 
> Links:
> ------
> [1] https://lists.freedesktop.org/mailman/listinfo/flatpak