[L2Ork-dev] CI build times

[Sam Thursfield]

Thanks for the input !

On Thu, Jul 30, 2020 at 1:13 PM Albert Graef <aggraef at gmail.com> wrote:
> One thing that works really well, though, is building Gem in parallel which reduces build times dramatically. This is in the current build system, you can trigger it by invoking `make` in the toplevel source directory like so:
>
> make GEM_MAKEFLAGS=-j8

That will be great as long as the system has enough memory to run 8
C++ compilers in parallel.

I took a quick look at the current CI today and it seems the slowest
build by far is the Raspberry PI. Is that a reasonably new one? If
not, a big CI improvement might be to simply buy one that's more
powerful :)

> Those obstacles remain no matter what you're going to use. I know autoconf, cmake, and meson reasonably well, and they would probably all be up to the job. But there's no magic wand in any of these build tools that will just make the complexities go away. If someone wants to take it on, I'm all for it! Be warned, though, that it's a *lot* of utterly tedious work, and needs to be tested *very* carefully on *all* the platforms we support. I certainly wouldn't want to be the poor sod who has to do it. ;-)

Absolutely! We can recommend to upstreams that they do the right
thing, but anything more involved would require quite a lot of funding
to make it happen, as with most long and tedious jobs.

However, it's unfortunate because I think Autotools is a bottleneck in
PD builds -- in particular `libtool`, which is a large shell script
that wraps every invocation of `gcc`, and is pathologically slow on
Windows (where every POSIX IO command goes through an emulation
layer), and on RPi (where everything is slow).

Since we can't compile things faster, I guess the only solution will
be to cache build results so we compile things less. The simplest
option is probably `ccache` -- i've opened an issue at
https://git.purrdata.net/jwilkes/purr-data/-/issues/665 about that.
Sam