Reducing build times of ldc-build-runtime

kinke noone at
Thu Mar 19 14:28:39 UTC 2020

On Thursday, 19 March 2020 at 10:22:31 UTC, Petar Kirov 
[ZombineDev] wrote:
> On Wednesday, 18 March 2020 at 16:25:56 UTC, Jacob Carlborg 
> wrote:
>> On 2020-03-17 22:33, kinke wrote:
>>> Yeah, 45 minutes is pretty short (and 11 minutes to compile 
>>> LDC very slow). An x86 simulator for Azure CI or so would be 
>>> pretty much unrestricted (6h time-out...).
>> With the free plan for closed source projects you only get 10 
>> minutes for each build. That won't get you far.
> A bit off-topic, but how does it compare to other services like 
> Azure Pipelines, GitHub Actions, BuildKite, etc. that support 
> self-hosted runners? (Also the first two have free macOS 
> runners and Windows runners.) From a quick look through the 
> page they indeed offer many features tailored to mobile dev,

> but at least for work, I wouldn't choose a CI solution that 
> doesn't offer support for self-hosting runners.

For work, I wouldn't choose any cloud solution at all. E.g., 
Azure has been a major pain in the ass the last week - python.exe 
not in PATH for some hours/days, afterwards PRs and pushes not 
triggering builds automatically for 2-3 days, and after that, 
I've had to create a new 'service connection' via GitHub PAT in 
order to successfully upload artifacts to the GitHub releases 
again. In the meantime, the MS apt servers like to fail from time 
to time due to checksum failures (yes, always the MS ones), so 
that `apt-get update` fails etc.

So if possible, I'd prefer to have an existing CI service be 
extended by a new iOS job, for a reduced maintenance burden. 
Azure's Mac VMs are quad-cores (unlike GitHub Actions for 
example, which only offer dual-cores; LDC compiles in under 4 
mins) and ship with Xcode + simulators, see

More information about the digitalmars-d-ldc mailing list