As we have previously discussed offline, the include-paths for headers within the core grackle library in the newchem-cpp branch have gotten a little messy, and it would be nice to have a more consistent set of conventions for include paths for private headers.
Essentially, there are 2 issues:
- include-paths for private headers within the grackle library
- include-paths for private headers needed by unit tests
Addressing issue 1 alone becomes far trivial if we just move every file source/header file from the src/clib directory into a subdirectory (then we would write every include-path relative to clib). For example, to include src/clib/tabulated/calc_temp1d_cloudy.hpp, you would write #include tabulated/calc_temp1d_cloudy.hpp. And maybe this is all we should focus on right now?
More properly adding include-paths for private headers used by unit-tests becomes a little more messy, and I definitely want to add my thoughts about this. While I think there is a straight-forward approach outlined with the simple solution described above, I have two other thoughts (we may/probably want to add a subset of logic to tests/grtestutils that is reused in gracklepy and we'll defnitely want to reuse logic from tests/grtestutils within some benchmarks) that make me think that we want to slightly adjust the directory structure (there are also some relevant build-system considerations).
But I'm out of time to flesh-out these thoughts at the precise moment. So I'll come back to this! (It's possible that after I write this out that I'll change my mind about restructuring)
As we have previously discussed offline, the include-paths for headers within the core grackle library in the newchem-cpp branch have gotten a little messy, and it would be nice to have a more consistent set of conventions for include paths for private headers.
Essentially, there are 2 issues:
Addressing issue 1 alone becomes far trivial if we just move every file source/header file from the
src/clibdirectory into a subdirectory (then we would write every include-path relative toclib). For example, to includesrc/clib/tabulated/calc_temp1d_cloudy.hpp, you would write#include tabulated/calc_temp1d_cloudy.hpp. And maybe this is all we should focus on right now?More properly adding include-paths for private headers used by unit-tests becomes a little more messy, and I definitely want to add my thoughts about this. While I think there is a straight-forward approach outlined with the simple solution described above, I have two other thoughts (we may/probably want to add a subset of logic to
tests/grtestutilsthat is reused ingracklepyand we'll defnitely want to reuse logic fromtests/grtestutilswithin some benchmarks) that make me think that we want to slightly adjust the directory structure (there are also some relevant build-system considerations).But I'm out of time to flesh-out these thoughts at the precise moment. So I'll come back to this! (It's possible that after I write this out that I'll change my mind about restructuring)