Appimage build process undocumented

[jhoblitt]

The appimage build procedure appears to be undocumented/scripted within in this repo.

[jhoblitt]

ping. This is a pretty major issue for linux devs that want to contribute.

[vojtechkral]

I agree it would be nice to have appimage building done as part of the project.
I don't see how it's stopping you from contributing on Linux though, can you elaborate?

[jhoblitt]

As there's no public CI, the build environment for a release needs to replicated as the dev env. Otherwise, there's no way to tell if a contribution will even compile in the release env. As an inverse example, I am able to build the current master on fedora 29 but it segfaults at start up. Is it because there's a different version of gcc, different tbb headers, etc.? I don't know and I don't want to have to debug it just for a simple contribution. Additionally, I do slicing on multiple different hosts and appimage is rather more convenient then having to build from source.

[probonopd]

It would be nice if a system such as Travis CI would be used to produce the AppImage. I can help doing this if people would like.

[LongLiveCHIEF]

The original Slic3r had a package directory at the root of the project, and used travis to create the appimage. I suspect this project just removed that bit after forking, but the build is likely the same or similar.

[bubnikv]

@LongLiveCHIEF

The original Slic3r had a package directory at the root of the project, and used travis to create the appimage. I suspect this project just removed that bit after forking, but the build is likely the same or similar.

Not true at all. PrusaSlicer was forked a lot earlier than that. To some extent we reuse the fruits of labor of each other. For example, the upstream slic3r was at its death bed 4 years ago because nobody was able to produce binary builds for all the pertinent platforms (slic3r-1.2.9 installers were built using Citrus Perl installer, which was long obsolete and it bundled old unstable UI libraries), until Prusa Researched hired and paid me to solve the binary distribution problem, which solution then has been adapted by the upstream slic3r. The draft of the CMake build system was provided by @craimer and finished by Prusa Research, then adopted by upstream slic3r. We at PrusaResearch are following the upstream development and we adopted most of their new C++ unit tests for example.

The upstream slic3r guys developed their travis build system long time after we had our internal build system. Our internal build system suits us well because it compiles quicker, which makes our continuous integration turnaround quicker than if using external servers.

[LongLiveCHIEF]

I'm not accusing you guys of anything, just trying to figure out how the appimage is built because I want to fix the annoying icon bug.

…

On Sun, Feb 9, 2020, 9:40 AM Vojtěch Bubník ***@***.***> wrote: @LongLiveCHIEF <https://github.com/LongLiveCHIEF> The original Slic3r had a package directory at the root of the project, and used travis to create the appimage. I suspect this project just removed that bit after forking, but the build is likely the same or similar. Not true at all. PrusaSlicer was forked a lot earlier than that. To some extent we reuse the fruits of labor of each other. For example, the upstream slic3r was at its death bed 4 years ago because nobody was able to produce binary builds for all the pertinent platforms (slic3r-1.2.9 installers were built using Citrus Perl installer, which was long obsolete and it bundled old unstable UI libraries), until Prusa Researched hired and paid me to solve the binary distribution problem, which solution then has been adapted by the upstream slic3r. The draft of the CMake build system was provided by @craimer <https://github.com/craimer> and finished by Prusa Research, then adopted by upstream slic3r. We at PrusaResearch are following the upstream development and we adopted most of their new C++ unit tests for example. The upstream slic3r guys developed their travis build system long time after we had our internal build system. Our internal build system suits us well because it compiles quicker, which makes our continuous integration turnaround quicker than if using external servers. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1253?email_source=notifications&email_token=AAZBLALLL64OOWM7VQFURRLRCAPWDA5CNFSM4FXEZEX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELGPWEY#issuecomment-583858963>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZBLALASRGRTY22LB5COLLRCAPWDANCNFSM4FXEZEXQ> .

[probonopd]

In the meantime, you could extract the contents of the AppImage using --appimage-extract, make your changes, and repack the AppImage using https://github.com/AppImage/AppImageKit/releases/download/12/appimagetool-x86_64.AppImage.

[hradec]

I have added a build script that uses docker container to build prusa slicer easier in any Linux distro and I've sent a pull request for it here: #12488

Unfortunately, I couldn't find any documentation or any build files required to create the appimage either (like the AppRun file, PrusaSlicer.png, etc).

It would be really amazing if I could just add the appimage build to this docker script too. (this docker script could be a starting point to use github actions to build, test and release nightly builds automatically)

So +1 on the appimage build documentation, please! :)

[wschadow]

for the appimage please see here #12383