| 33 | | * Should `include` be part of this? Some projects have it at the top level. |
| | 33 | * Is it "everything worth compiling" or perhaps just C, C++ and Python code or even just C and C++ code? |
| | 34 | * Example is locale. But also docs is compiled. |
| | 35 | * Should `include` be part of this? |
| | 36 | * Some projects have it at the top level. |
| | 37 | * Some projects divide code into src, include and apps. Should we use that too? |
| | 38 | * This may help separating dirs for module families (raster, vector, ...) from the rest of the source code. |
| | 39 | |
| | 40 | Current challenges (strangenesses): |
| | 41 | * `include` contains things for make, so any includes would go here? E.g., Jinja templates if we would have some or more realistic example `*.cmake` files. |
| | 42 | * `include` does not contain grass, but the header files are there directly. Common source code layout nowadays is to have a directory named as the resulting directory in the distribution, i.e., not `include/*.h` but `include/grass/*.h`. This makes it easier for many code editing tools. |
| | 43 | * Python code in `lib/python` is next to C libraries which may look like it is a C library to communicate with Python. |
| | 44 | * `lib/python` suffers from the same as header files in `include`. In this case it is even little more serious because it breaks rules on how a Python package should look like. Again, dir named `grass` should be inserted before the dir with the subpackages. |
| | 45 | * `gui/wxpython` again similar to `include` and `lib/python` because there is no "package" directory, but a greater reorganization may be needed as the "wxgui package" is not even in the distribution and the subdirectories are all top-level packages. |
