Binary releases for tools

[wilzbach]

While it's debatable whether dfmt etc. should be shipped by default with the D installer, it might be worthwhile to provide binary releases for people (especially for Windows).
A couple of ideas:

One bundle per platform

Probably one bundled release archive for each platform is enough (people interested in only one tool should be capable of compiling it themselves, using dub or maybe even a distro package one day)

Advertise the use of DUB

DUB already simplifies the process and at some point dub run dfmt might be merged (it will automatically fetch dfmt if it isn't available before running). However, if I look the the repos the use of DUB isn't documented at all. So that's something moderately easy that can be done.

Automatically create Linux binaries with Travis

We could improve the Travis CI pipeline (or use a different CI), s.t. on each commit to master all tools are bundled and uploaded to S3 (or similar)

Automatically create Windows binaries with AppVeyor

We could add appveyor to automatically create these bundles for Windows (example)

Common release version for "official" releases

Defining a common release version for "official" releases might be tricky, but we could try to synchronize the releases with the DLang releases or release a bundled release every one/two months

[wilzbach]

I started an experiment with D-Scanner a while ago and it looks like using Travis's GH release feature works quite well:

See also: dlang-community/D-Scanner#539

Of course the next interesting steps would be

• agree on a naming scheme

• do the same for macOS (probably a bad time at the moment with Travis having so many OSX issues)

• do the same for Windows. It's apparently not too hard either:

• https://www.appveyor.com/docs/deployment/github/

• https://www.appveyor.com/docs/deployment/#deploy-on-tag-github-and-gitlab-only

[skl131313]

The build.bat need to be fixed for a few of the repos. There's no way to specify which target to build x86/x64, dmd defaults to 32-bit and ldc2 defaults to the host arch. So the bat file always creates the same binary for each config, on appveyor.

It'd be nice to have a dub install dfmt feature. That builds and puts the dfmt binary somewhere that PATH searches for it. That way it can be used from the console without having to use dub again, and other applications like some IDEs can then find it as well.

[wilzbach]

One step further: Linux/OSX binaries uploaded to GH release:

• Deploy binaries to GitHub releases (Linux/MacOS) DCD#458
• Deploy binaries to GitHub releases (Windows/Linux/MacOS) dfmt#348
• Improve the binary release building (Linux, OSX) D-Scanner#573

The build.bat need to be fixed for a few of the repos.

Would be cool if we can do something similar for AppVeyor too.

It'd be nice to have a dub install dfmt feature. That builds and puts the dfmt binary somewhere that PATH searches for it. That way it can be used from the console without having to use dub again, and other applications like some IDEs can then find it as well.

Yep. It's an open feature request for quite a while:

dlang/dub#839 (and has a lot of up votes)

Anyhow the best we get for now is:

dub fetch ...
dub run ...

and with dlang/dub#1082 that could be just dub run

[wilzbach]

If building things under Windows is such a pain, we could try to use Wine - for example for D-Scanner:

wget http://downloads.dlang.org/releases/2.x/2.079.0/dmd-2.079.0.exe
wine dmd-2.079.0.exe
wineconsole build.bat

The automated version is a bit longer:

wget http://downloads.dlang.org/releases/2.x/2.079.0/dmd.2.079.0.windows.7z
7z x dmd.2.079.0.windows.7z
DC=$(realpath ./dmd2/windows/bin/dmd.exe) wineconsole build.bat

Here's the binary built in Wine:

dscanner.windows.zip

Would that work for everyone?
Oh and there's a LDC cross-compilation dockerfile to OSX:
https://github.com/jacob-carlborg/docker-ldc-darwin/blob/master/Dockerfile

We might be able to adapt that to Windows.

See also: https://hub.docker.com/r/multiarch/crossbuild/

[jacob-carlborg]

For Linux I think we should build completely statically linked binaries, -static, and on macOS we should specify a minimum deployment target, -macosx_version_min 10.7 -lcrt1.o to make the binaries available on as many version and distros as possible.

[wilzbach]

For Linux I think we should build completely statically linked binaries, -static

I agree that -static is really cool (and in this org I use it for D-Scanner's Docker Image), but what about older Linux kernels?
I actually checked this and if I use a modern Linux kernel as a host, then I will get an "unsupported kernel" error if e.g. run on 2.6.26 (I know it's EOL, but many systems still use it).

on macOS we should specify a minimum deployment target, -macosx_version_min 10.7 -lcrt1.o to make the binaries available on as many version and distros as possible.

OK. Testing here -> dlang-community/D-Scanner#598

[jacob-carlborg]

I agree that -static is really cool (and in this org I use it for D-Scanner's Docker Image), but what about older Linux kernels?
I actually checked this and if I use a modern Linux kernel as a host, then I will get an "unsupported kernel" error if e.g. run on 2.6.26 (I know it's EOL, but many systems still use it).

This Linux binary https://github.com/jacob-carlborg/remarkify/releases/tag/v0.0.1 is built using Travis CI and fully statically linked. Running file on it gives back: for GNU/Linux 2.6.24. It runs on RHEL/CentOS 6 which has kernel version 2.6.32-NNN. RHEL 6 was released eight years ago and RHEL is usually very conservative with updating versions. How old kernels do you need it to work on? I don't see how it will be any worse than if it's dynamically linked.

[wilzbach]

OK looks like this is host-dependent then. FYI: I gave it a try in dlang-community/D-Scanner#598 then ;-)