FUCKING stupid defaults. CMake's default no less stupid. I'm MAD, why
would anybody even want to have the build run sequentially on todays
machines?! If your build is crap and can't run in parallel, FIX YOUR
CODE, but don't make the other 99% users suffer!!
It's just not worth the pain. I have to reduce the parallelism from 24
to 6, and yet it still sometimes gets stuck. And at that point it's
about twice as slow, so there's not really any gain from this costing
half the credits.
This reverts commit 9d61a63553.
This reverts commit 9c4f2ceea2.
This reverts commit 80b7694468.
I'm running out of the 400k free monthly credits and since macOS takes
50 credits per minute vs 5 for the Linux Docker, it's the obvious
candidate. ARM and Android take 10 instead of 5 and since we don't have
any ARM-specific code and the Android ES3 build doesn't run GL tests,
it's also non-essential.
Will revert this at the start of Junly.
The main part of the build time is fetching packages (where I doubt
multithreading can help anything) and running tests, which is serial to
have the output reasonably ordered. The actual build time takes less
than a half of the total time so going with the smallest resource class
instead of the medium shouldn't make that much of a difference. But it
uses half the credits, and that's what matters.
Required for Buffer::data()/subData() used by GLES3 tests. Otherwise
all the tests would have to check the Emscripten version and skip if
it's too old.
TBF I have to thank CircleCI for sending me no less than three warning
e-mails about Xcode image deprecation. I just didn't bother
updating until it started actually failing.
There's a lot of places in the code that assume macOS is never GLES, and
with the increasingly rotten native GL support on Apple platforms people
are switching to ANGLE. So we should make sure this use case works.
Well, no wonder it OOMs with 38 parallel jobs on ~10-20 GB RAM depending
on how the VMs are loaded, heh. Will revisit when I get rid of more STL,
this has to suffice for now.
On Ubuntu, because SwiftShader Vulkan doesn't compile on GCC 4 (or 5)
anymore, we use 4.8 on 16.04 for compile-test against libvulkan-dev and
18.04 for render-test with SwiftShader.
On Mac, because we want to work with both MoltenVK and Vulkan Loader, we
compile-test against MoltenVk in the generic "all build" and render-test
against SwiftShader on a new, Vulkan-specific build. That requires us to
supply our own loader as well -- apparently no such thing is on
Homebrew, which is kinda silly (doesn't anybody do real Vulkan work on
this crazy platform?!).
Vladimír Vondruš