Flatpak build #11
Comments
|
So then are you volunteering to help with that? Sorry I'm a bit late looking into this, I've never built or used Flatpaks.. So first impressions, it looks like a lot of work for not a lot of benefit. Laidout in an AppImage is almost ready and is far easier to create and maintain. |
You don't need to use portals (without using Gtk or Qt, it would be a lot of effort to implement anyway). You can give your app the same file system permissions as a regular non-flatpak app. |
|
I'd be happy to help someone who wants to take on Flatpak building! If old fashioned c style file access (fopen, fread, fwrite, etc) and whatever libgraphicsmagick is doing can still be used just by changing app file permissions, then hopefully it's just a matter of finagling build scripts. I imagine Laidout's AppImage build script (which works great) would be a good place to start. |
|
I would volunteer to write the build manifest, but somebody else would have to maintain the app on Flathub. |
|
Hmm, the Flathub docs seem to say maintaining apps there is mostly git repo updating, provided the app meets app guidelines, which doesn't sound so hard. If that's true, and assuming very permissive filesystem access doesn't violate app guidelines, I could probably maintain it there IF you or someone else figures out how to build successfully. If it turns out maintenance there is way more involved than it sounds, my support there might be inconsistent, as I must focus my personal efforts on Laidout's tools, and not build systems. I mean unless someone gives me lots of money for particular things. Happy to help others to improve build systems though! Side question, do you know if flatpak/flathub has any special requirements about .so based plugins? Particularly, can apps dlopen random things from someone's hard drive? The AppImage build just forces everything into the build, and ignores whether something is technically a plugin internally (the easiest solution). Currently this is only about Gegl nodes in Laidout, but my intent is to expand plugin features for libs that have horrible dependency troubles on some distros. Lumping everything together is fine by me, just looking for more info to make sure my approach to plugins in Laidout isn't terrible. |
|
Couldn't get it to build: |
No, but flatpak has it's own extension system.
Bundling everything would the preferred solution for flatpak in this case too. |
|
Hmm.. What version of g++ are you using? Seems like g++ is ignoring template instancing. Can you try configuring laidout with: If that doesn't work, try removing lines 114 and 112 in become: Over time g++ seems to get more picky about when and where template code gets compiled and linked. I have a few template implementations in .h/.cc files, instead of having everything in header files.. Supposedly the compiler will ignore duplicate compilations of template instances, but for some reason if i do all header templates, resulting executables are about a megabyte larger, and compiling takes longer. |
Adding |
|
It's expecting a file called makedepend, which should have been made during a Before compiling anything, try: |
|
|
For instance, the AppImage build script is here: Since that script was written, I updated Laidout's configure so that you shouldn't have to manually mess with Laxkit or download a separate icons repo. Just make sure that To sum up, the normal steps for compiling from git master for a public release to an executable that might be moved around (like AppImage or FlatPaks) are supposed to be something like: For simplicity, you can add |
|
It appears I had not fully implemented the auto-configuring of Laxkit from Laidout! |
|
Ok, more fixes in master for both Laidout and Laxkit. Also cleared a lot of those warnings. |
|
I opened a PR with the flatpak build files, because I guess this will get solved faster, if you can build it yourself locally. |
|
It would only be faster if one assumes I can already do flatpak builds on my kind of old machine! Until I have time and resources enough to upgrade my system, I don't really want to install a gig of flatpak related build environment. Does it still fail on your machine? |
Yes. |
|
Would you have time to upload another build failure log? Debugging misery loves company! It seems like this is close to being resolved, my current build system is usually easy to hack with enough information about failures. At any rate, ideally we'd have a github workflow that can automatically build flatpaks. The appimage script runs via TravisCI, and was made before github workflows were really functional. |
You might take inspiration from this PR: obsproject/obs-studio#3804 |
|
Interesting. Though someone still has to do the work! I'll probably have more time for build workflows myself when I'm closer to the next "Stable" release, hopefully "soon". In the meantime, I'm happy to address error logs people can post. |
Please, consider supporting Flatpak and publishing Laidout on Flathub.
The text was updated successfully, but these errors were encountered: