> 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 list
>> SG15_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>