Feedback on spec

[uecasm]

I assume that this repository is related to this specification; I couldn't otherwise find anywhere appropriate to give feedback after reading that.

1. The link at the top of the page to the specification itself is broken.
2. Why is it that submodules are forbidden from containing further submodules? While directory depth can be a concern, it seems like a bad idea to restrict this.
3. When using Separate Header Placement, is cat/sounds/meow.cpp expected to #include <cat/sounds/meow.hpp> or #include "../../../include/cat/sounds/meow.hpp"?
4. In Source Directory Layout, does this imply that a library should always declare symbols in a non-global namespace (and thus in Separate Header Placement there would never be any files in the top-level include or src directories)?
5. What is the reason for suggesting that tests could be implemented in the src directory? Doesn't this conflict with the idea that the library should not build its tests when consumed from another library?
6. Generated files are explicitly forbidden from being in include or src. Where then do they go? How is this reconciled when generated files need to be compiled or included by library consumers? What if the library consumer is not expected to be able to run the tool which generates the file?

[vector-of-bool]

That document is indeed related to this project. The code from which it is rendered is kept this in this repository. I don't yet have a general location for feedback, as I've just been fielding it from all around the Internet in various forms and formats. Using a GitHub issue here is as valid as any.

Thank you for your feedback! These are some useful questions and comments.

1. Yeah... It's still a "draft"-ish, and I haven't set up the dedicated page for it yet.
2. I've answered this questions elsewhere, but it may warrant inclusion in the document: The relationship and inter-dependencies between submodules within a single project is not a tree, but a directed graph. You cannot easily represent a directed graph using a plain filesystem. As such, a submodule which builds upon another submodule should not be in a child directory, but a sibling directory, where the dependency between them is encoded in the project build and configuration, rather than the filesystem.
3. The former. include/ and src/ are added to the include search path when compiling the project. .. in an include directive is very suspicious.
4. This is correct: Projects should not declare unqualified symbols. (This is distinct from the global namespace, as a C project may still conceptually "namespace" its symbols using qualified identifiers). This does imply that there will be no source files at the top-level of include/ and src/. I'm reserving top-level sources for a different purpose, which may or may not be included in the future.
5. Having a .test.cpp file alongside its source component does not necessitate building that test file. While it is easy to simply exclude the tests/ directory at the top level, it is still possible (and not particularly difficult) to exclude the compilation of .test.cpp files within src/
6. This document doesn't speak much in terms of the installation tree. Generated files may be installed alongside the hand-written ones. When using a project as an embedded subdirectory, the build for the subproject will ensure that the generated sources will end up on the include path of the consumers. For example, a CMake target can add the generated header directory to the public include directories to the target in question, thus ensuring that consumers are able to see these generated headers.

[GrantRobertson]

The relationship and inter-dependencies between submodules within a single project is not a tree, but a directed graph. You cannot easily represent a directed graph using a plain filesystem. As such, a submodule which builds upon another submodule should not be in a child directory, but a sibling directory, where the dependency between them is encoded in the project build and configuration, rather than the filesystem.

Is this the reason why use of src and include preclude the use of libs and extras, and vice versa? Normally, I would assume a primary or main (sub)module to be a "parent" of sorts to a submodule, and thus should be in a higher level folder. However, if one thinks of a project as a directed graph of submodules, then it's entirely possible that the only distinction between a "main module" and all the others is that that is where the program starts.