Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Needed rework of my script to generate the Appimage #289

Merged
merged 5 commits into from
Mar 2, 2025

Conversation

bawsdeep
Copy link
Contributor

@bawsdeep bawsdeep commented Feb 17, 2025

Improved AppImage Build Process for Better Compatibility
The previous AppImage was built on a rolling-release distribution (Arch Linux), which caused compatibility issues for users on stable distributions with older package versions. This meant they couldn't run the AppImage unless they built it themselves—something I admittedly should have tested on other distributions. Lesson learned.

What's Changed
To ensure broader compatibility across distributions, we've introduced a new build process:

Docker-Based Build: The AppImage is now built inside a Docker container, which the script sets up and cleans up automatically.
Clean Builds Every Time: The script runs in no-cache mode, ensuring a fresh build with every execution.
Mac Compatibility: The script should theoretically work on macOS as well, which is useful since Andrew plans to build it locally. The free plan of Docker should be sufficient, possibly without requiring an account.
Detailed Documentation: A comprehensive README is included to guide users through the process.
This update should provide a more reliable and consistent AppImage experience across different Linux distributions.

Let me know if you have any questions! 🚀

@PraveenAsh
Copy link
Contributor

This is good! Is there a way to do it for Windows and present a Unified Script? The builds take really long and if containers can solve for all OS then building in cloud over a script would be amazing. More of a CI/CD Process. When a new version tagged, CI/CD trigger and build on cloud instance -> dump to S3(or any storage). Would save a lot of time tbh!

@bawsdeep
Copy link
Contributor Author

bawsdeep commented Feb 24, 2025

This is good! Is there a way to do it for Windows and present a Unified Script? The builds take really long and if containers can solve for all OS then building in cloud over a script would be amazing. More of a CI/CD Process. When a new version tagged, CI/CD trigger and build on cloud instance -> dump to S3(or any storage). Would save a lot of time tbh!

There is no reason to adapt it to Windows the Binaries are already available in the Beta Releases
all my script does is to pack the prebuild Folder into a Single binary for Linux Andrew can just offer a single Binary instead of a folder

@andrewpareles
Copy link
Contributor

Thanks for this, this is great.
Is there a reason to rename to void-...? I have some other scripts that use this file so would ideally keep it vscode, is this used anywhere in the script you added?

@bawsdeep
Copy link
Contributor Author

Thanks for this, this is great. Is there a reason to rename to void-...? I have some other scripts that use this file so would ideally keep it vscode, is this used anywhere in the script you added?

do you mean the rename in the gumpfile ? that change wasent made by me

@andrewpareles andrewpareles merged commit f711c68 into voideditor:model-selection Mar 2, 2025
@andrewpareles
Copy link
Contributor

Great stuff!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants