= GRASS 8 new source layout = Rationale: At the moment source directory top level is a mess — distribution / OS specific folders are mixed with source code folders. Moving all source to src would make directory layout cleaner. G8 release is a great opportunity to break everything to make life better. Keep in mind — this is just a proposal to start discussion! Add your input to make it happen. == Folder structure == How to read: new folder name at the top level, current folders listed below. How to write: add your comments to any item you think should be moved somewhere else etc. === CI === Continuous Integration: scripts, lists of dependencies, configurations which are not part of the specific CI configuration files. Not all files will be here. For example workflows of !GitHub Actions will be in their dedicated directory. Questions: * Do we need this as a separate entry or it should go into packaging? * It is not clear which dependencies go. * CI is also running tests which is not necessarily (main focus of) packaging. === doc === Documentation, that is not individual module help files. * doc === src === All source of GRASS. Should contain everything worth compiling. Questions: * What would qualify as compiling or source code? * Is it "everything worth compiling" or perhaps just C, C++ and Python code or even just C and C++ code? * Example is locale. But also docs is compiled. * Should `include` be part of this? * Some projects have it at the top level. * Some projects divide code into src, include and apps. Should we use that too? * This may help separating dirs for module families (raster, vector, ...) from the rest of the source code. Current challenges (strangenesses): * `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. * `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. * PR:1350 * Python code in `lib/python` is next to C libraries which may look like it is a C library to communicate with Python. * `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. * https://github.com/OSGeo/grass/issues/1100 * PR:1356 * `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. Subdirectories: * db * display * general * gui * imagery * include * lib * locale or should go to the top level? * misc * ps * raster * raster3d * scripts * temporal * vector === packaging === Every distribution or platform specific scripts, build recipes etc. Questions: * Are there some packaging systems that require its related files to live on the top level? * Not strictly packaging, but related, if we have a Binder (mybinder.org) setup, it would require a top-level directory, so in general, there are cases like this. Subdirectories: * docker * macos * mswindows * rpm * singularity * tools/vagrant => vagrant === utils === Helper scripts not intended to be installed as a part of GRASS package. * Content of tools (which should not be called tools, that's too close in meaning to modules). * The main tools to utils rename done in PR:1348 (merged). * Other utilities from man, doc, etc. === tests === Testing infrastructure. Questions: * We don't really have a separate tests directory now with all tests. We have tests spread in the individual directories they test. So the question is if there is enough on the top level to go into this dir. Subdirectories: * demolocation * It is used for more than just testing, namely as default location/data/project. * testsuite * Since we take the approach of tests being close to the source code, this could likely be distributed to most relevant directories.