You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
They expect that an AppImageKit build on their build farms will use their existing libappimage package, similar to how USE_SYSTEM_MKSQUASHFS works here.
Obviously they are then responsible for making sure their libappimage and other deps are appropriately patched until all relevant patches are upstreamed , i.e. #815
This would be interesting to me! Currently the repo can not be built without checking out the git submodules.
Previously I tried to build this as a third-party dependency in Bazel using http_archive (Which downloads the code archives automatically generated by GitHub - which do not include submodules) and rules_foreign_cc / CMake. This fails because the archive does not contain the CMakeLists.txt being included to build libappimage.
If USE_SYSTEM_MKSQUASHFS was implemented I could first build libappimage separately and then provide it to the build for appimagetool 👍
Activity
lalten commentedon Apr 3, 2022
This would be interesting to me! Currently the repo can not be built without checking out the git submodules.
Previously I tried to build this as a third-party dependency in Bazel using http_archive (Which downloads the code archives automatically generated by GitHub - which do not include submodules) and rules_foreign_cc / CMake. This fails because the archive does not contain the CMakeLists.txt being included to build libappimage.
If
USE_SYSTEM_MKSQUASHFSwas implemented I could first build libappimage separately and then provide it to the build for appimagetool 👍Remove libappimage git submodule
Remove libappimage git submodule
Remove libappimage git submodule
probonopd commentedon Nov 25, 2024
No longer actively used.