Open wilzbach opened 7 years ago
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: https://github.com/dlang-community/D-Scanner/pull/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/#deploy-on-tag-github-and-gitlab-only
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.
One step further: Linux/OSX binaries uploaded to GH release:
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:
https://github.com/dlang/dub/issues/839 (and has a lot of up votes)
Anyhow the best we get for now is:
dub fetch ...
dub run ...
and with https://github.com/dlang/dub/pull/1082 that could be just dub run
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:
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.
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.
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 -> https://github.com/dlang-community/D-Scanner/pull/598
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.
OK looks like this is host-dependent then. FYI: I gave it a try in dlang-community/D-Scanner#598 then ;-)
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 fetchdfmt
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