Indeed, that was my reaction also. Getting a 60-40% result in my read means there’s nearly 0 consensus. That being said, I don’t think that any such layout should reach +80% in any direction. The compilation workflow will never be mandated, C++ cannot do the same what Rust has pulled off by having Cargo. If (ever) there’ll be a canonical project layout, it will be:

- slow to gain adoption
- will never reach +80% of the codebases
o partly because of legacy
o partly because of wild usage of source code generation
- should provide ample benefit to support

I might have said it before, but agreeing on a recommended/canonical layout could serve as the common interface to calling the compiler from the STL. If the compiler were part of the STL, many of the code generation woes would go away, so long as the code generator can be written in C/C++. With an HPC background I naturally have things in mind such as OpenCL, where loading device code (kernels) at run-time, tuning them based on device capabilities and compiling them via a convenient API call is as easy as 1-2-3. Single source GPGPU APIs are nice, but sometimes it would come in handy to be able to call the compiler again at run-time to make command-line arguements compile-time constants and enroll them into TMP.

I’m not entirely sure either whether such attempts should bother rationalizing gazillions of lines of legacy project layouts. Maybe instead we should focus on standardizing (recommending) the use of modules? That way there’s no legacy to take care of, there are no production modules out yet. Using #include is the Wild West where anything can happen, but using modules could be a nicer experience, not just from a source code POV but a compilation model view as well.

Boris’ original proposal seems legit though, but I think it’s completely orthogonal as to how the original dependencies were built, with what layout. The proposes dependency model treats upstream as a total black box and only requires that the installation layout holds public headers in the expected way.

Another interesting aspect which I believe should be taken care of is the ability to query the compiler for ABI-compatible compiler switches. This touches upon my initial idea of having a „tool-aware” build system, where following that idea compilers could communicate ABI changing flags to control recompilation of dependencies, perhaps including STL/OS header behavioral defines (like UNICODE chars on Windows, for eg.). Again, restricting ourselves to pre-processor immune modules shields us from dealing with ABI changing #defines. If a binary package would communicate the set of compiler switches it was compiled with and one could ask the compiler: „if I compiled myself like this ${}, am I link compatible? This might be as simple as a something along the lines of feature test macros. A cnostexpr function taking two vectors of strings and returning a boolean. That might make the life of package repo vendors and contributors easier. Vcpkg need not treat EVERY triplet as incompatible.

Feladó: David Sankel
Elküldve: 2018. június 15., péntek 12:59
Címzett: WG21 Tooling Study Group SG15
Tárgy: Re: [Tooling] C++ project layout pool

On Fri, Jun 15, 2018 at 1:28 AM Boris Kolpackov <boris_at_[hidden]> wrote:
A quick summary of the results: with ~300 answers, ~60% for the split
layout (public headers in include/, sources and private headers in
src/) and ~40% for the combined (everything in a single directory).

Does anyone think that a solution which requires >=40% of C++ codebases to change their directory layouts is likely to achieve consensus?