Again, this is not for prebuilt libraries. This is literally replacement
for "CMakeLists.txt" file

On Tue, Nov 26, 2024 at 3:44 PM Steve Downey <sdowney_at_[hidden]> wrote:

> 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
>>
>