Thanks @jan
Just a quick note…
The snap is confined, so it cannot easily integrate with other components.
An example is that modules installed via pack_install work (if they do not depend on other system dependencies)
Packages installed from the system package repo or other methods will not.
The alternative is to use a “classic” confinement, giving the snap full access to the system (as it is for deb/rpm packages).
It mostly depends on the use case, so I’d like feedback on this as well.
Most languages are indeed available as “classic” unconfined snaps.
Another note is that (adding the qt dependencies) the classic snap would be larger, since it would not depend on a qt “library” snap.
@LyzardKing thanks for these notes. I guess the reason for confined or not depends on the target users of this snap. The snap is a great way to get a pretty complete and up-to-date installation running in seconds. apt/dnf also get you a version in seconds, but old on most Linux distros.
Packs containing foreign code typically won’t work, for start because make is not available 
Install "rserve_client-1.2.0.zip" (31,760 bytes) Y/n?
ERROR: source_sink `path(make)' does not exist
Confined should be attractive for some people as well though, as is small. We’ll see …
That’s why it might be better to build it as a classic snap.
We can add make to the snap, but that would be limited. Any other dependency would be missing.
If the snap was built without confinement it might be easier to support foreign code.
I’m not sure. It might even be possible to make both via channels (https://snapcraft.io/docs/channels)
Or to focus on one approach. although I’m not sure which is better.
Seems we could use tracks? Anyway, let us first see how people react.
1 Like
Hi @LyzardKing, I did some more checks for releasing 8.1.29 as snap. Added tcmalloc, which works fine. Also added missing jquery from libjs-jquery. Am I right to see this popup as
/snap/swi-prolog/current/usr/share/javascript/jquery/jquery.min.js
rather than
/usr/share/javascript/jquery/jquery.min.js
edit
Seems the snap wants jquery in /snap/kde-frameworks-5-core18-sdk/current/usr/share/javascript/jquery, but this directory does not exist.
edit 2
So the build finds it in the -sdk/ which is not there in the deployment. Added a hack to the CMake script to compensate. Uploaded 8.1.29 to snap.
Hi!
The jquery.min.js should be in:
/snap/kde-frameworks-5-core18/current/usr/share/javascript/jquery/jquery.min.js
If it’s possible it should be set at runtime…
This is why the snap looks at the -sdk directory, because that’s what is used at build time…
It might be possible to add the non -sdk at build time, so it can pick the right folders…
I’ll try…
Yes, that is what I eventually figured out. CMake now finds it in the sdk and adjusts the directory by dropping -sdk from the path. The snap pattern is quite unique, so it is pretty unlikely this will break anything. Its a hack, but its not the only one dealing with portability and there are dirtier ones 
Most seems ok. Three issues remain which gives a rather poor first time experience (and that is quite likely what snaps are for).
- After every install of the snap I have to run
sudo rm /var/cache/fontconfig/*. I think most users will not like that
- First time you start it it complains about a locale “en” that is not found. Next time it runs silent.
- The
swipl-winconsole by default does not use a monospace font. That is not an issue of the snap, the same happens on the normal version. Didn’t check the Mac. @CapelliC, do you have an idea?
If it works by adding the non -sdk snap in the .yaml file you can remove the hack…
I asked about the fontconfig in the snapcraft forum… if you want to add your voice to it here: https://forum.snapcraft.io/t/fontconfig-issue-in-snap-kde-neon-extension/16706/3
I haven’t encountered the locale issue, but i’ll look at that after…
1 Like
I’d assume the -sdk version has the development libs and headers and the non-sdk one not? We need those to build the X11 and Qt dependencies.
Yes, you’re correct.
But I have seen the path issue solved in other cases by adding the non -sdk as well as the -sdk at build time…
I’ll test it just to see, but it’ll take a while since my internet connection these days is my phone…
It might work if you can mount both and set DCMAKE_FIND_ROOT_PATH= to search both and the non-sdk version first. My hack is in packages/http/CMakeLists.fxf
It uses Courier by default. Should be monospace… or, as the docs put it, the font matcher prefers fixed pitch fonts.
Not sure what I should/could fix…
I propose this patch. This puts the Qt config files in the same dir as the (now) XDG swi-prolog config files and follows hints from this StackOverflow question.
Pushed this, but I’m happy to revert or adapt if you have something better. Tested on Ubuntu 19.10, where I now get a good looking fixed font as default.
2 Likes