On Monday, 31 August 2020 at 13:24:50 UTC, wjoe wrote:
On Saturday, 29 August 2020 at 18:40:36 UTC, Iain Buclaw wrote:
On Thursday, 27 August 2020 at 04:05:15 UTC, M.M. wrote:
On Monday, 24 August 2020 at 23:49:42 UTC, Iain Buclaw wrote:
[...]
Likely the deciding factor will come down to how much free
time I will get to do so. There's still a few outstanding
issues in dmd-master and gcc middle-end that have hampered
progress by a few weeks.
Thank you for your work. I cross my fingers for you to have
enough free time in the upcoming months!
If people want to share my workload on gdc, then it'll
certainly help.
I'm exactly 100% unfamiliar with the code base. How can I help
? Where do I start ?
Some parts of the infrastructure could do with some TLC.
CI currently uses semaphore CI for native x86_64, and Buildkite
with a couple
hosted Linux VMs for testing various cross-compilers. I used to
have ARM and
ARM64 bare metal servers with Scaleway, but sadly they decided to
scrap them.
Ideas that could be investigated:
1. Is Cirrus CI good enough to build gdc? And if so, look into
adding
Windows, MacOSX, and FreeBSD platforms to the pipeline.
2. Likewise, have a look a Github Actions, they have Windows
and MacOSX.
3. Use Docker+QEMU to have containers doing CI for other
architectures, can
build images for Alpine and Debian on amd64, arm32v7,
arm64v8, i386,
mips64le, ppc64le, and s390x.
4. I can order VMs with x86_64 FreeBSD and OpenBSD installed
for CI purposes.
DragonflyBSD might also be possible as well (I'll have to
ask for images).
5. Should builds be packaged up as possible downloads?
There are some compiler/library programming tasks that go with
it, for each
platform/cpu combination that currently lacks run-time support.
1. Add relevant target support to GCC. I have patches, just
not committed to
mainline due to lack of testing.
2. Ensure that druntime builds and is functional on the
platform.
Iain.
