I'm aware of problems with "Yet another X" or "There were 10 solutions, so
we created our own. Now there are 11 solutions". If I wasn't aware of that,
I would go implement a new one. That's why I'm here. Only way to avoid this
is, "standard says it". This is not %100 solution to that, but at least it
wouldn't be yet another solution nobody uses since the industry standard is
CMake. People pretty much hate CMake, at least parts of it. But they can't
do anything about it because it's the industry standard. Some does, but
they don't get to benefit using a solution which is industry standard

On Wed, Nov 27, 2024 at 4:44 AM Steve Downey <sdowney_at_[hidden]> wrote:

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