binary Windows releases (on github)

[c33s]

it would be nice to have binary releases on github (including windows). for golang tools it is quite common that they provide multiplatform builds on github.

[bagder]

If someone wants to work on that I'll help out, but it's not a priority for me personally.

[bagder]

lots of distros already ship trurl.

[c33s]

having a official windows binary would still be a thing

[bagder]

Agreed. It would be great if someone provided such.

[fragolinux]

@bagder i started working on this a few days ago, but had no time to go on... if you want to take a look...

it builds, but both gh actions files should be merged in a single one using matrix, so there will be a single final release, with all the artifacts generated and attached to it...

or maybe 2 files, 1 for build and 1 for release...

right now, the fastest build will push the binary and create release, the slowest follows and halts overwriting the other built one (different arch), and cannot create a new release because it already exists...

once merged these 2 files in a single build one, i think the windows part should be trivial to add...

edit: i see now that you already build the 3 platforms, so you're just missing the "upload artifacts" and "release" steps

[bagder]

I would presume that for Linux and macOS this is less interesting than for Windows.

[fragolinux]

I would presume that for Linux and macOS this is less interesting than for Windows.

why? Having binaries instead of just sources published on releases page would allow to release an asdf plugin, too, to have this versioned

[c33s]

i also think that having official binaries for all platforms is good thing. being able to simply wget the binary with the latest version from the official source is so nice. not having to wait for third parties until they update their packages or fiddle around with docker. one of the main reasons i meanwhile narrow my search to golang for small cli tools (sometimes rust too) - they offical sources ship binaries.

[bagder]

If someone wants to provide builds for any platform, feel free to work on it.

[fragolinux]

If someone wants to provide builds for any platform, feel free to work on it.

@bagder done! :D example release: https://github.com/fragolinux/trurl/releases/tag/v0.6.0

[vszakats]

I've added trurl to curl-for-win. For now I did not enable it in the live releases, but if we agree that this would be desired, it's certainly possible. Let me know.

They are already present in the daily curl-for-win builds: https://github.com/curl/curl-for-win/actions/workflows/daily.yml

FWIW it's not only Windows (3 CPUs), but also LInux MUSL (amd64, aarch64, riscv64), Linux glibc (amd64, aarch64, riscv64) and macOS (Universal Apple Silicon + Intel).

[vszakats]

Windows builds are running now in CI.

For release purposes it may use a slightly different configuration, for a bit smaller binaries with longer build times. Otherwise the existing CI logic can be re-used for this Issue almost as-is. The question is where to upload the result, how to trigger it and adding the necessary logic for these.

It would be a better way to distribute trurl than adding them to the official curl package. The latter features shared trurl.exe (~40KB), while the ones here are building a static trurl.exe with a thin libcurl, making it 350-400KB per .exe.

UPDATE: After further optimizing thin libcurl, .exe size is down to 250KB. And 189KB without IMAP URL options support.

[vszakats]

After another round of optimizations with trurl builds, the size of the reference Windows ARM64 turl.exe is down to 89KB with IMAP, and 53KB without. Can use "unity" mode now without side-effects on build size. It means the existing CI process can be reused as-is for live builds.

[vszakats]

Either the thing suggested in the last comment could be used to pull this off, though it'd be a new process and someone needs to do it. It could probably be done in GHA with results uploaded to the Release page. (I have no recipes ready for this.)

Or, to avoid the extra work, it's possible to enable trurl in official curl-for-win builds. In such case, it'd be using the existing curl/libcurl build process, which builds a "universal" libcurl lib (= not specifically optimized for trurl, meaning much larger in size). This would make a static trurl.exe almost as large as curl.exe. It means it's only practical to link to libcurl.dll. Which in practice means that the curl-for-win binary directory needs to be added to the PATH or both libcurl.dll and trurl.exe copied to a directory in PATH. This breaks the static promise of the curl-for-win distribution, but may be an acceptable compromise.

turl.exe has been included that way in the 'daily' curl-for-win builds for quite a while now: https://github.com/curl/curl-for-win/actions/workflows/daily.yml

[bagder]

Thanks @vszakats, I think we can live with getting it from the the curl-for-win daily builds until someone provides something else.