💾 Archived View for bbs.geminispace.org › u › sy › 19785 captured on 2024-12-17 at 15:04:26. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
@skyjake What is the regular way to build/install clagrange?
I've built it on macOS, but cannot use the binary if I copy it to PATH. The resource file is searched only in the binary's directory or some non-existing dirs.
It works fine in the build dir, though. (And supports emojis better than Lagrange via terminal)
Uncommenting the debug line in source, and running from ~/.local/bin/:
Resources: Checking /Users/user/.local/bin/resources.lgr Resources: Checking /lagrange/resources.lgr Resources: Checking /Users/user/share/lagrange/resources.lgr Resources: Checking /Users/user/.local/bin/share/lagrange/resources.lgr Resources: Checking /Users/user/.local/share/lagrange/resources.lgr Resources: Checking resources.lgr failed to load resources: No such file or directory
Sep 20 · 3 months ago
🕹️ skyjake [...] · Sep 20 at 18:12:
IIRC, on macOS, you have to set the resource file location at compile time to some predefined place. This is because the application is unable to determine its executable's location in the file system for doing relative lookups. I believe this is prevented for security reasons. In my prebuilt binaries I've set it using the CMake option `-DRESOURCES_LGR_PATH=/usr/local/share/clagrange`.
Also IIRC, it works from the build directory because the lookup can be done relative to the current working directory.
Thanks, will try. There's already a ~/.config/lagrange directory. Wouldn't that be also searched by default?
(Also added some debug info to my original post)
🕹️ skyjake [...] · Sep 20 at 18:20:
The .config directory is not searched for resources.lgr, mostly because of the increased risk of getting a version mismatch. "resources.lgr" is usually strongly tied to a particular release of the app, so one must minimize the possibility of obsolete .lgrs hanging around and getting loaded by accident.
At one point I was embedding the .lgr inside the executable to make this foolproof, but that became unwieldly once there was 20+ MBs of fonts included.
Now the .lgr is back at ~4 MBs so I might again start embedding it, though.
clagrange needs no fonts or image assets, so embedding the resources is likely the best solution here. I'll just need to generate a TUI-specific subset of the .lgr for embedding.
I've built v1.18.1 with `-DCMAKE_BUILD_TYPE=Release -DENABLE_TUI=ON -DRESOURCES_LGR_PATH=/Applications/Lagrange.app/Contents/Resources` to sync resources between builds. But clagrange adds the default bookmarks again for each run. I have `~/.config/lagrange/cprefs.cfg` and `~/Library/Application Support/fi.skyjake.Lagrange/prefs.cfg` files. Do I need another cmake flag pointing to to the config?
🕹️ skyjake [...] · Sep 29 at 13:01:
I have actually seen that as well, the duplicated initial bookmarks, and it's a bug. I'll fix it for the next release...