I wouldn't want to end up just respecifying the ninja database, but on
the other hand, I also don't want to respecify posix make.

What would be the requirements list that isn't covered by p3286
<http://wg21.link/p3286> ?

On Mon, Nov 25, 2024 at 6:46 PM James via SG15 <sg15_at_[hidden]>
wrote:

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