Date: Tue, 26 Nov 2024 15:39:56 +0200
Bret Brown via SG15 <sg15_at_[hidden]> writes:
> 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
We've also came up with a (different) canonical project structure
as part of the build2 work[1] (a subset of which was proposed to
SG15[2]). What was surprising is the amount of indignant push-
back we've got when our ideas did not match what each reader was
used to (especially in the header inclusion area).
This experience made me realize that any "canonical" project format
for C/C++ has no chance of adoption; there will always be a
substantial percentage of users who will religiously cling to their
preferred ways. Hell, I myself will religiously cling to not having
the include/src split ;-).
This realization also forced us to add quite a bit of flexibility
to our "new" command that creates project templates, especially
where the source code layout is concerned[3].
And this in turn gave rise to this idea: what if instead of
standardizing a single canonical structure we provide a standard
way to describe the various layouts that are found in the wild.
Build system vendors can then teach their "new" commands to
generate the "implementation" for each layout. Paired with
wildcard patterns for source code discovery this will effectively
give us a portable "build by many conventions" where the user
can switch build systems by re-generating the build files (the
next step would be to generate the build system on the fly).
Just to give a concrete example of what this might look like,
here is the build2 "new" command line to create a library with
the include/src split that uses the .hpp/.cpp file extensions
and relies on automatic symbol exporting on Windows:
--lang c++ --type lib,split,extension=?pp,auto-symexport
For the complete list of available customizations see [4].
[1] https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#proj-struct
[2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1204r0.html
[3] https://build2.org/bdep/doc/bdep-new.xhtml#src-layout
[4] https://build2.org/bdep/doc/bdep-new.xhtml
> 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
We've also came up with a (different) canonical project structure
as part of the build2 work[1] (a subset of which was proposed to
SG15[2]). What was surprising is the amount of indignant push-
back we've got when our ideas did not match what each reader was
used to (especially in the header inclusion area).
This experience made me realize that any "canonical" project format
for C/C++ has no chance of adoption; there will always be a
substantial percentage of users who will religiously cling to their
preferred ways. Hell, I myself will religiously cling to not having
the include/src split ;-).
This realization also forced us to add quite a bit of flexibility
to our "new" command that creates project templates, especially
where the source code layout is concerned[3].
And this in turn gave rise to this idea: what if instead of
standardizing a single canonical structure we provide a standard
way to describe the various layouts that are found in the wild.
Build system vendors can then teach their "new" commands to
generate the "implementation" for each layout. Paired with
wildcard patterns for source code discovery this will effectively
give us a portable "build by many conventions" where the user
can switch build systems by re-generating the build files (the
next step would be to generate the build system on the fly).
Just to give a concrete example of what this might look like,
here is the build2 "new" command line to create a library with
the include/src split that uses the .hpp/.cpp file extensions
and relies on automatic symbol exporting on Windows:
--lang c++ --type lib,split,extension=?pp,auto-symexport
For the complete list of available customizations see [4].
[1] https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#proj-struct
[2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1204r0.html
[3] https://build2.org/bdep/doc/bdep-new.xhtml#src-layout
[4] https://build2.org/bdep/doc/bdep-new.xhtml
Received on 2024-11-26 13:38:50