There’s one place where I’m getting stuck: I can’t figure out how to include SQLite 3, which the app depends on. FluffyChat seems to accomplish this by including two cmake dependencies: olm and libjsoncpp. Both seem to yield a /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 file, even though neither are directly related to SQLite.
I don’t have a need for any of these libraries, but I do need SQLite 3. How do I do that?
For reference, this is my current Flatpak YAML draft:
ln -s /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 /app/lib/libsqlite3.so
ln: failed to create symbolic link '/app/lib/libsqlite3.so': No such file or directory
You can try to debug your module with flatpak-builder --build-shell=timecop BUILDDIRECTORY MANIFEST. This prepares your build environment for the given module & starts a build shell. There you can manually execute your build-commands & inspect your source directory as well as the /app destination.
You should replace cp -R /usr/bin/ /app/timecop with cp -R timecop /app/timecop to copy your application into the /app-prefix (you’re currently copying the binaries of the SDK into your app).
SQLite 3.36 is already part of the Platform (freedesktop-sdk). It shouldn’t be necessary and probably avoided to build it unless a specific or newer version is required.
That’s not why the symbolic link fails, since the library exists (this works: flatpak run --command=ls org.freedesktop.Platform//21.08 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0).
Thanks a ton! Your tip helped me debug he problem. Beside the cp bug that you noted, I also needed to mkdir and then it worked.
Now I’m dealing with a filesystem permission issue. It seems that both getDatabases() in SQFlite as well as getApplicationDocumentsDirectory() in path_provider point to somewhere outside the sandbox in the home directory. I’ll look into it when I get the time and if I can’t figure it out, I’ll create a new thread.
For now, I’ll be setting the --filesystem=home permission.
I can’t say anything about SQFlite, but getApplicationDocumentsDirectory() resolves into the user visible documents folder (usually $HOME/Documents) and therefore requires --filesystem=xdg-documents.
If you want to hide your files inside $XDG_DATA_HOME, you have to use getApplicationSupportDirectory (this doesn’t require any filesystem-permissions).
I ended up using XDG_DATA_HOME from xdg_directories. It probably does the same thing, but it was easier to discover for me, and it also seems more future-proof to me.
I also ended up duplicating a file opened from a file picker to a temporary location, though I’m not sure that’s necessary.
I discovered quite late that despite using --force-clean, my binary was not being updated during installation. --disable-cache did the trick.
(My Linux set-up is painful in that my Linux computer has a tendency to randomly freeze up and become unresponsive for hours due to a hardware issue. Other than that, I have a Mac with basically no hard disk space, so VM is out of the question. Testing different builds is quite burdensome, which is why I haven’t tested not copying an imported file to a temp location.)
Anyway, seems like I’m at the finish line. Now just need to make sure that my changes aren’t causing regressions on Android or iOS.
digital ocean is another method if you don’t have workflows working.
You can make a build script and setup an environment and finished within
8 minutes.
You need to choose a droplet that has 4gb of ram. $28 server works… it will cost almost nothing if you destroy the server immediately.