Wyatt Childers <wcc_at_[hidden]> writes:

> The authors of these projects and their custom build systems are arguably
> /less likely/ to move to a "standard build system format" (that they have to
> port their build to, relearn, and provides them nothing other than "being
> standard") than they are to add support to those build systems for build
> system interop.

I am not sure about that. Projects like ICU and OpenSSL don't use
custom build systems because they want to be different, they use
them because none of the widely-used ones cover their use-cases.
I believe if a widely-used build system ("standard" or not) becomes
available that can handle their use-cases cleanly, they will consider
migrating (maybe with some help).


> > 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.
>
> I don't foresee us being able to solve these problem; they're a cost of
> having a diverse ecosystem.

This cost very quickly becomes prohibitive. While I agree we will
unlikely ever be able to reduce it to 0 (which would entail having
a standard C/C++ build system that everyone uses), we maybe could
make it palatable by reducing the problem from N build systems to
2 build systems: end-user build system that the user uses to develop
their application and the "feeder build system" that is used to
build all their dependencies.