Although it started with an edge-case, the need to keep custom launch logic in some form - I would expect - is much more widely required by other projects. So what we need is the ability to shim custom logic into the launcher from the AppRun and it doesn't need to be obscure, we just need to know how we should tackle this problem. AppImage as our preferred portable format (as a benchmark, our current release has 16,000 downloads in 2 months - we consider. So, the root of the issue was the first environmental variable - but - the need to add more has made this just-in-time-custom-environment much more important as we embrace. AppImage format, such as non-relocatable JACK libraries and other shims such as specific, nested folders that weren't being added to the LD_LIBRARY_PATH, we continued using this shim and it's been an important part of how we launch our software. Then, later, as we started to hit very specific issues with the.We used the foo.real shim and linuxdeployqt automagically found our binary and everything worked.In our case, it was an environmental variable for QT that we needed to set (something we'd consider and edge-case). ones that touch the environment before launching. desktop file as the source of the bundle - but - we found it didn't work properly with custom Exec= commands, e.g. When we started integrating linuxdeployqt it was strongly encouraged to use the.So some additional background on all of this. I'll quote my message to the linuxdeployqt project. Long-term, if Carla's launch support were part of it's main executables I suspect AppImage would bundle it without much fuss. The Carla scripts rely on Python3-Qt4 but AppImage doesn't yet have support for bundling the scripting framework by pointing to a script file (and we probably don't want to), so it's simply too complex to ship in an AppImage for now. Yes off-topic and it should probably be put on the back burner because AFAIK it would have to be done by hand. Not much related to this issue, but I think we may consider bundling Carla and using it when missing. I'll let chime in, we can't be the only project needing fine-grained control over the launcher. I'm not sure how we're supposed to do this. The hack - which I had originally questioned but also which is now considered a bug - allows the tool to ignore the. We need to inject some runtime information at LMMS launch, and we need to have our own script for that, but the linking tool needs it by its original name to bundle all of the dependencies. I also wonder why we substitute the Exec entry back to lmms after running linuxdeployqt. Probably, but this is the third time we've had to write additional logic like this because upstream changed their mind. I think we should remove the problematic symbolic link and manually create desired one. Without it, the whole foo.real trick is worthless. Bug? No, it's how we were told to use the script by It's here: #3688 (comment)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |