2020-10-05 02:34:11 +02:00
|
|
|
|
Fancy build: grand unified build system for all and sundry.
|
|
|
|
|
|
|
|
|
|
|
|
Models constraints of and is able to interoperate with any other build system.
|
|
|
|
|
|
(Ideally. In practice, something like scons will be impractical; but make,
|
|
|
|
|
|
cargo, cpan, dub, etc. are fine.)
|
|
|
|
|
|
|
2020-10-05 09:23:19 +02:00
|
|
|
|
Pros:
|
|
|
|
|
|
- Fast
|
|
|
|
|
|
* Don't do any more work than you have to
|
|
|
|
|
|
+ SCons, redo, and bazel (and bazel's derivatives--buck, please, etc.)
|
|
|
|
|
|
get this right. Most others (make, ninja, etc.) don't.
|
|
|
|
|
|
× ninja has an open ticket to resolve this, but maintainers seem
|
|
|
|
|
|
uninterested in resolving it. (https://github.com/ninja-build/ninja/issues/1459)
|
|
|
|
|
|
+ Example: purely syntactic (not semantic) change shouldn't require a re-link.
|
|
|
|
|
|
* Parallel
|
|
|
|
|
|
- Correct
|
|
|
|
|
|
* Always rebuild if you have to
|
|
|
|
|
|
+ SCons, redo, and bazel&co (again) get this right.
|
|
|
|
|
|
+ Example: update system c compiler or headers.
|
|
|
|
|
|
× For some, even just updating locally-referenced headers is enough.
|
|
|
|
|
|
- Easy to use for tiny projects, but programmable enough to scale indefinitely
|
|
|
|
|
|
* SCons hits these points, but it's slow; not pathologically so, just incidentally.
|
|
|
|
|
|
* Redo uses shell, which has difficulty with abstraction.
|
|
|
|
|
|
* Ditto make.
|
|
|
|
|
|
* Bazel (and derivatives) are interesting:
|
|
|
|
|
|
+ Reasonably powerful programming language
|
|
|
|
|
|
+ Build description for a toy project looks reasonable: 5
|
|
|
|
|
|
lines indicating source and target files.
|
|
|
|
|
|
But:
|
|
|
|
|
|
+ Heavyweight. Slow startup time is solved by running a persistent build
|
|
|
|
|
|
server; not unreasonable for google-scale projects but that seems like
|
|
|
|
|
|
overkill when you look at the 20-line build description it executes.
|
|
|
|
|
|
+ Builtin build rules insufficiently introspectible or modifiable.
|
|
|
|
|
|
For example, changing the toolchain used, or the build flags, is much
|
|
|
|
|
|
more complex than it need be--than it is, in most build systems.
|
|
|
|
|
|
× Partly, this is just because those build rules don't expose hooks to
|
|
|
|
|
|
modify those attributes. But mostly it's because the build language
|
|
|
|
|
|
doesn't lend itself well to such dynamism, so it's not encouraged.
|
|
|
|
|
|
× (https://github.com/bazelbuild/bazel/issues/2954,
|
|
|
|
|
|
https://github.com/bazelbuild/bazel/issues/4644)
|
|
|
|
|
|
It's not a problem that such bugs exist, but it is a problem that
|
|
|
|
|
|
they can't be easily fixed or worked around 'in userspace'.
|
|
|
|
|
|
|
|
|
|
|
|
The closest build systems to solving all these are SCons and Shake
|
|
|
|
|
|
(https://shakebuild.com/). SCons is slow. Compared with shake, we have:
|
2020-10-05 02:34:11 +02:00
|
|
|
|
- No conflation of build targets with on-disc files. Represent deployment,
|
|
|
|
|
|
dependencies from (network) package registry, ...
|
2020-10-05 09:23:19 +02:00
|
|
|
|
- Build starts instantly. No need to build your build file.
|
