When I first came into this conversation (on Slack), I was under the
impression that we were not requiring a layout.

Merely, we were giving recommendations, and then giving the go-ahead to any
tools that detect the recommended layout to have a much easier time
generating the build description with minimal amount of user input (or none
at all). I do not expect (and do not want) anyone in the 60-40 split to
change anything about their project, nor do I expect anyone with even
crazier build trees to change. Our solution should work with any build tree
layout, since I expect any build description meta-information format to
have the capability to have one big fat list of "these are all the source
files you should be looking at, these are all the 20 include places you
need to be using when utilizing this target/component".

It is important to note, however, that I fully expect -- after we cover the
big cases of "Big Explicit Lists Because Our Build Is Crazy" -- that we
also provide ease of use and shortcuts for those in the future and today
who use one of the recommended build buckets (everything in /source, or
split into /include and /source). conan already does things like assume
that the top-level /include is the include directory you want by default,
and these defaults are Good and Sane. Incentives such as "your build is
automatically generated if your directory structure is well behaved" makes
future adoption easy, and helps stop the growth of out-of-control project
structures.

Part of our job _is_ providing some sanity for build systems for the
future, no?

On Fri, Jun 15, 2018 at 8:05 AM, Nagy-Egri Máté Ferenc <
nagy-egri.mate_at_[hidden]> wrote:

> 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
> - partly because of legacy
> - 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 <camior_at_[hidden]>
> *Elküldve: *2018. június 15., péntek 12:59
> *Címzett: *WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
> *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?
>
>
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>
>