Date: Wed, 27 Nov 2024 19:51:30 +0100
Python does something similar where there are different buildings systems
like hatchling, poetry etc but all of them follow pyptoject.toml which had
some standard settings for most common usage and then each buomd system can
have its own custom config.
On Wed, Nov 27, 2024, 14:54 Boris Kolpackov via SG15 <sg15_at_[hidden]>
wrote:
> 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.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
like hatchling, poetry etc but all of them follow pyptoject.toml which had
some standard settings for most common usage and then each buomd system can
have its own custom config.
On Wed, Nov 27, 2024, 14:54 Boris Kolpackov via SG15 <sg15_at_[hidden]>
wrote:
> 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.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2024-11-27 18:51:46