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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15