Well, just having something standard instead of "there are a bunch of
solutions, pick one and go" is a major improvement in terms of complexity.
It doesn't mean other solutions will become unavailable, I find it very
similar to non standard compiler extensions. They are still there, but when
you use it, it's not portable anymore.
Also I think we can do better than what most build systems offer these
days. In terms of complexity and ease of use

On Tue, Nov 26, 2024 at 2:05 AM Wyatt Childers <wcc_at_[hidden]> wrote:

> I think a simple file format is possible. I could implement a simple
> enough JSON-based one in CMake itself. Assuming a couple other build
> systems add support for the same format, we would have something we could
> standardize meaningfully. I expect we'll help a *lot* of the ecosystem by
> simplifying interop with a standard in this space.
>
> I think that's a bit of ... trying to find a problem for a solution.
>
> Maybe a standardized project description is the best way to specify
> interop, but I think the focus in that area should be on interop.
>
> Realistically, I don't expect to be able to build a project that uses
> build system Gamma without having build system Gamma installed on my
> machine. Even in the case of a common format, I would imagine build system
> Zeta would invoke Gamma to get the details of the build (and thus Gamma
> would have to be installed).
>
> 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).
>
> - Wyatt
>
>
> On 11/25/24 17:40, Bret Brown wrote:
>
> I think a simple file format is possible. I could implement a simple
> enough JSON-based one in CMake itself. Assuming a couple other build
> systems add support for the same format, we would have something we could
> standardize meaningfully. I expect we'll help a *lot* of the ecosystem by
> simplifying interop with a standard in this space.
>
> That being said, I expect the utility of that approach will diminish as
> project complexity increases. It's widely counterintuitive, but having a
> Turing-complete build configuration does have the upside of supporting just
> about anything you if you really, really want to. Without forking your
> build tool. For instance, arbitrary dependency discovery, ecosystem
> specific project layout support, or modeling of arbitrary development
> tooling like bespoke code generators or linters.
>
> Bret
>
> On Mon, Nov 25, 2024, 22:07 Wyatt Childers via SG15 <sg15_at_[hidden]>
> wrote:
>
>> I'm skeptical of viability here... a major portion of what constitutes
>> the build system itself, is *how the project is described*.
>>
>> - Wyatt
>>
>>
>> On 11/14/24 17:53, James via SG15 wrote:
>>
>> Has there been any consideration for establishing a standardized format
>> to describe C++ projects that could be universally recognized by different
>> build systems? This wouldn’t involve creating a new build system, but
>> rather defining a common file format that accurately describes project
>> structure, dependencies, and build requirements in a standardized way.
>>
>> The goal would be to improve interoperability and developer experience
>> across different build systems and generators, also allowing projects to
>> seamlessly transition between them without modifications to the project
>> file itself.
>>
>> Additionally such a change could improve tooling and IDEs, enhancing the
>> developer experience even more!
>>
>> _______________________________________________
>> SG15 mailing listSG15_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>
>>
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>
>
>