Hacker News Reader

Comment by Animats | Hacker News Reader

I'm trying to build the same Rust program for Linux, Windows, and MacOS. Cross-compiling isn't the hard part. Rust can make Windows executables on Linux. Making an installer is. Most of the installer builders only run on Windows and use Microsoft components. "Inno", an ancient freeware program, will run under Wine. But it outputs an old-style .exe installer, not a newer .msi installer.

Packaging for Linux isn't much better. There's .deb, for which you need a "repository". There are "snaps", which is Canonical's scheme for getting developers under control of their App Store. There was Flatpak, but Canonical is trying to kill that off. There's AppImage, but the code to build those hasn't been updated in two years. There's always .zip files.

Not sure how to package for MacOS yet.

View on HN

This is why i don't think the concept of an "installer" should be the way software gets published and distributed to end users. Very few software packages actually _need_ to have installers - things like system/hardware drivers are the ones that come to mind.

Instead, use the portable apps model (https://portableapps.com/) , where you have a single binary that runs, and can be deployed by a simple copy/extract. Ditto with uninstallation.

This is what MacOS has, so that's why mac software is just a bundle inside a directory (that ends in `.app`).

For Windows installers from Linux, check out NSIS...

https://nsis.sourceforge.io/Main_Page

From the features page:

"The NSIS compiler can be compiled for POSIX platforms like Linux and *BSD. Generated installer will still run on Windows only, but this way they can be generated without Windows or WINE."

Oh, Nullsoft. Hadn't heard of them in decades.

That generates an executable installer, not a .msi file or its more recent successor. But the installers will run on Windows 95!

Flatpak is still alive and well: it's commercially supported by Red Hat and has quite a following, especially in the GNOME world. It's last release was last month. Usually a user of Debian packages, I must admit that for desktop use Flatpak is a very slick solution.

Yeah, but I don't want to buy into the Flatpak vs Snap war.

Does anyone still use AppImage, or is it dying out?

AppImages are still widely used, it's just that the tooling surrounding them sucks.

At the end of the day, they're glorified zip files, not much different to self-extracting .exe files, and you'll have to figure out what libraries your application needs to run on various distros. Some bundlers attempt to do this for you but they're not infallible, so be prepared to test in different VMs.

> AppImages are still widely used, it's just that the tooling surrounding them sucks.

I just discovered that the hard way.[1]

[1] https://users.rust-lang.org/t/packaging-a-rust-application-f...

As a side-note, the snap vs flatpak war is essentially canonical vs everyone else. It's easy enough to install flatpak on ubuntu distros, it's harder to install snap on some other distros where flatpak works wonders.

If you're worried, you can also just, do both. A packaging overhead of 2 is still better than maintaining your own distro- and version-specific packages, unless you submit it to the distros yourself or get others to package it for you.

You can use WiX Toolset version 4 to create Windows installers. Version 3 is Windows-only, but Version 4 runs under .NET "the-one-that-runs-on-Linux". It produces MSI files.

https://wixtoolset.org/docs/intro/

You can just rename the macos binary to .app and it'll work. But generally you want an actual .app bundle, I made a tool for that in the past (in rust too!) slmjkdbtl/packapp you can check it out, i think the official apple docs are referenced in the source as well

I scripted Inno Setup running on Wine with bash for a really hacky internal CI thing for a while. The compiler will even run (via Wine) without X!

Just statically include everything in one executable. Or release the source and let others build & package it for their favourite OS.

This is an application for end users. Remember them?

Using a single executable file will make their life easier. And some users will be "power" users and will know how to package something. Make use of your user community.

There's only one executable, with no .dll or .so files. It needs some text and image assets that don't need to be in memory all the time, so I don't want to nail them into the running executable. (You can do that in Rust, and I do it for a few minor icons such as arrows that aren't going to change. But not for big stuff.)

Reply on news.ycombinator.com