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

Initial migration to Meson #31

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

desiderantes
Copy link
Collaborator

This migration uses a baseline of Ubuntu 22.04 for deps.

  • Pixmap embedding migrated to GResources.
  • Redid Logo as SVG
  • Simplified config fle generation

Missing:

  • macOS packaging
  • Windows Packaging

@desiderantes
Copy link
Collaborator Author

Not sure how much of a blocker windows support is, since current iss script is tailored to the original author's PC, which tells me there's no real support.

@ferdymercury
Copy link
Owner

I think the original author focused on providing the Windows binaries:
https://amide.sourceforge.net/installation_windows.html

If you want, we could create in the meanwhile a dev branch in this repo doing the meson migration. Thanks!!

@desiderantes
Copy link
Collaborator Author

desiderantes commented Nov 1, 2023

Yeah I saw the compilation steps. Extremely manual. I think i'll focus on getting the macOS .app thing done first. As I see it, there's four options for building a Windows Installer that we can use:

  • Inno (.iss) [current]
  • NSIS (From WinAmp)
  • Wix 3/Wixl (Wixl is native to linux, which means we could build .msi files from a cross-compilation)
  • MSIX (Supposedly the future for UWP apps on windows, and would also work from linux)

I'm partial to the last two options, because it allows future automation like Ci/CD to happen within a single run.

@desiderantes
Copy link
Collaborator Author

And for the dev branch... I think I prefer to finish the basics on all three platforms first and then start a refining process on a more official branch (and maybe rewrite history in the process). How does that sound like? I don't feel very strong about it so if a dev branch is preferred that's OK

@ferdymercury
Copy link
Owner

Let's keep it simple and use the main branch as you suggest. We should just tag well the releases in Github to be able to go backward if something breaks :)

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.

2 participants