The description of where to find all of the parts of a shipped module
interface source and translate that to a BMI for consumption by the rest of
a project is at least a largish subset, as it can also involve resolving
includes and imports, as well as the multiple partitions.

On the other hand, there's a ray tracer built in Cmake. Not with, in.

What parts of a problem are you suggesting a solution to, and who's life is
improved by it? I understand you want to do more than CPS, but I'm not
clear on what, that isn't just yet another build system?

On Tue, Nov 26, 2024, 20:30 James <james.business.84_at_[hidden]> wrote:

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