Date: Tue, 26 Nov 2024 15:08:18 +0200
Wyatt Childers via SG15 <sg15_at_[hidden]> writes:
> It seems much more beneficial to specify the standard interop where Zeta
> passes information to Gamma, Gamma builds the external project and then
> gives the build artifacts back to Zeta. Then I can in my Zeta build system
> just say "I want to use library X, here are the source files" (and then we
> can later specify some kind of package management that builds on that with
> source/binary fetch).
I agree, this sounds sensible in theory but in practice this approach
doesn't scale very well. Specifically:
Firstly, there won't be just Gamma and Zeta, there will be a handful of
build systems involved. Say, my project needs ICU (custom build system,
requires Python), OpenSSL (custom build system, requires Perl), Curl
(automake), Boost (Boost Build), and Qt6 (CMake plus who knows what
for a long list of dependencies). That's at least 5 different build
systems.
This has some unfortunate implications:
1. If things go wrong (and they always go wrong in this area), you
need to be knowledgeable in multiple build systems.
2. When you need support for a new platform or compiler, you are
dependent on other build systems to provide the same support.
3. With different build systems you have to build things one-by-one
in the dependency order. This can substantially reduce build
parallelism.
4. With different build systems you would often have to build the
entire project even though you may only need a small part. For
example, ICU is actually three libraries but you may only need
some subset of them.
> It seems much more beneficial to specify the standard interop where Zeta
> passes information to Gamma, Gamma builds the external project and then
> gives the build artifacts back to Zeta. Then I can in my Zeta build system
> just say "I want to use library X, here are the source files" (and then we
> can later specify some kind of package management that builds on that with
> source/binary fetch).
I agree, this sounds sensible in theory but in practice this approach
doesn't scale very well. Specifically:
Firstly, there won't be just Gamma and Zeta, there will be a handful of
build systems involved. Say, my project needs ICU (custom build system,
requires Python), OpenSSL (custom build system, requires Perl), Curl
(automake), Boost (Boost Build), and Qt6 (CMake plus who knows what
for a long list of dependencies). That's at least 5 different build
systems.
This has some unfortunate implications:
1. If things go wrong (and they always go wrong in this area), you
need to be knowledgeable in multiple build systems.
2. When you need support for a new platform or compiler, you are
dependent on other build systems to provide the same support.
3. With different build systems you have to build things one-by-one
in the dependency order. This can substantially reduce build
parallelism.
4. With different build systems you would often have to build the
entire project even though you may only need a small part. For
example, ICU is actually three libraries but you may only need
some subset of them.
Received on 2024-11-26 13:07:14