Date: Mon, 25 Nov 2024 15:10:00 +0000
I am not aware of anything approaching a standard project structure for C
or C++ projects. I would include a standard configuration schema as a
subset of projects with standard structures. They, after all, are projects
with standard structures regarding discovery of configuration files!
Anyway, existing work in this space includes the pitchfork project
structure, which does not support all of the use cases that Boris is
thinking about: https://github.com/vector-of-bool/pitchfork
I suppose the CMake, Meson, build2, Boost Build, etc. project structures
are all well specificied but not standard.
A surprising amount of important C and C++ (but mostly C) is organized
using project structure for other languages, such as python, node.js, etc.
I will say that the lack of a standard or even interoperability facilities
in this space is a pain point. For instance, the Beman Project [1] is
attempting to facilitate good papers and implementations for ISO standard
library proposals, but it is inventing tooling and project layout
conventions as it goes, which would ideally be both boring and out of scope
for a project that is trying to focus on C++ library research and
development.
For the record, I think the CPS specification, which intends to help build
systems work with one another, is essential to this entire project. I am
hopeful that it will make it easier to try out simpler (or more powerful!)
build systems with less concern for ecosystem incompatibilities. That
ideally would include configuration and convention standards to allow at
least simple projects to trivially support more than one build system.
Bret
[1] The Beman Project Exemplar is the in-progress template for what new
library projects in this umbrella would start out looking like. Note it is
using "best practices" CMake as it's project structure for a few reasons,
but there's definitely need for something simpler and more portable.
https://github.com/bemanproject/exemplar
On Mon, Nov 25, 2024, 14:09 Boris Kolpackov via SG15 <sg15_at_[hidden]>
wrote:
> Harald Achitz via SG15 <sg15_at_[hidden]> writes:
>
> > Probably this: https://cps-org.github.io/cps/
>
> I don't think it is. From the linked website:
>
> > Like pkg-config files and CMake package configuration files, CPS files
> > are intended to be produced by the package provider, and included in
> > the package’s distribution. Additionally, the CPS file is not intended
> > to cover all possible configurations of a package; rather, it is meant
> > to be generated by the build system and to describe the artifacts of
> > one or more extant configurations for a single architecture.
>
> In other words, this format describes an artifact produced by one
> build system to be consumed by another. What James is asking for is
> a standardized description of how to produce said artifact.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
or C++ projects. I would include a standard configuration schema as a
subset of projects with standard structures. They, after all, are projects
with standard structures regarding discovery of configuration files!
Anyway, existing work in this space includes the pitchfork project
structure, which does not support all of the use cases that Boris is
thinking about: https://github.com/vector-of-bool/pitchfork
I suppose the CMake, Meson, build2, Boost Build, etc. project structures
are all well specificied but not standard.
A surprising amount of important C and C++ (but mostly C) is organized
using project structure for other languages, such as python, node.js, etc.
I will say that the lack of a standard or even interoperability facilities
in this space is a pain point. For instance, the Beman Project [1] is
attempting to facilitate good papers and implementations for ISO standard
library proposals, but it is inventing tooling and project layout
conventions as it goes, which would ideally be both boring and out of scope
for a project that is trying to focus on C++ library research and
development.
For the record, I think the CPS specification, which intends to help build
systems work with one another, is essential to this entire project. I am
hopeful that it will make it easier to try out simpler (or more powerful!)
build systems with less concern for ecosystem incompatibilities. That
ideally would include configuration and convention standards to allow at
least simple projects to trivially support more than one build system.
Bret
[1] The Beman Project Exemplar is the in-progress template for what new
library projects in this umbrella would start out looking like. Note it is
using "best practices" CMake as it's project structure for a few reasons,
but there's definitely need for something simpler and more portable.
https://github.com/bemanproject/exemplar
On Mon, Nov 25, 2024, 14:09 Boris Kolpackov via SG15 <sg15_at_[hidden]>
wrote:
> Harald Achitz via SG15 <sg15_at_[hidden]> writes:
>
> > Probably this: https://cps-org.github.io/cps/
>
> I don't think it is. From the linked website:
>
> > Like pkg-config files and CMake package configuration files, CPS files
> > are intended to be produced by the package provider, and included in
> > the package’s distribution. Additionally, the CPS file is not intended
> > to cover all possible configurations of a package; rather, it is meant
> > to be generated by the build system and to describe the artifacts of
> > one or more extant configurations for a single architecture.
>
> In other words, this format describes an artifact produced by one
> build system to be consumed by another. What James is asking for is
> a standardized description of how to produce said artifact.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2024-11-25 15:10:15