5 ms·
Can you write about the reasons for much faster builds, as far as you know? Is it mainly due to the zig's caching of the build artifacts?
by acqq 4y ago
Can you write about the reasons for much faster builds, as far as you know?
Is it mainly due to the zig's caching of the build artifacts?
- aidenn0 4y agoI'm not who you are replying to, but it's almost certainly due to autoconf &c. For many libraries on a machine with lots of cores, autoconf can take longer than the build, since autoconf isn't parallelized.
- ploxiln 4y agoAlso, IIRC, many smaller projects using autoconf have copied in a bunch of boilerplate feature tests that they don't need, like "is strncpy available" "is snprintf available" "does realloc NULL work". As you mention, each one of these tests generates and compiles a minimal C file, and not in parallel. (And each test generates/defines a HAVE_SNPRINTF etc macro that your code can use to adapt based on available features. But if the project isn't as big as curl or git, it probably doesn't really adapt to all possible old and obscure systems anyway, so there's no point to 100s of such tests.)
- acqq 4y agoThanks, both are good general tips, but in this specific case https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium I would guess that the author of the library has full control both over optimal parallelization of a build and minimal autoconf, but he can still observe a huge speedup, so I'd still like to read his answer.
- jedisct1 4y agoThis is not due to autoconf. It's faster than the `make` command, i.e. after autoconf has generated everything. Building the tests, in particular is instant with zig, not with make. It may still be autoconf, but not the configure phase, rather the complexity of the generated makefiles.