Directory structure
It might be helpful if we imposed some more structure on the repository. In particular it might be nice to place source files in a src
directory and to put generated object files, module files etc. into a build directory.
I have done this for GS2 previously (in a local repository) so should be able to implement it quite easily but it may possibly cause headaches for merges if a large number of files have been moved (I didn't experience this previously but I was working alone).
Comments (6)
-
-
- changed milestone to 8.1
-
reporter Yes that's probably a good idea -- in principle I think git should be smart enough to handle it but safest to wait a bit (I suppose we can always test it in a branch to see if it works out ok). There are several things that have to be changed to achieve this both in the makefile and the dependency generator but overall it should be relatively straight forward.
We should probably try to decide on the directory structure in an organised way - so to start things off I have a proposal
/src -- Source files (/src/geo -- Source files for geometry etc.) /programs -- Source files defining programs (essentially Aux but ensuring GS2's main goes in there as well) /tests -- the testing stuff /docs -- documentation /externals -- place we put all external code (including utils I guess) /Makefiles -- I'd be keen to put this in externals but that might be a breaking change for some /scripts -- useful tools for dealing with gs2 /pipelines -- location for all files dealing with our various CI approaches # Upon building we'll also have /bin -- executables generated /lib -- libraries generated /include -- module files from build /build -- object files from build
-
I think this structure is good. I also like the idea of dividing
Makefiles
intoMakefiles/Compilers
andMakefiles/Systems
. -
reporter Yes! I've done that previously as well (I may have mentioned it or I might not have) -- there's a slight issue in that we can't just do
include Makefiles/Systems/Makefile.whatever
as users might provide their ownMakefile.whatever
on a different path so we'd have to update guidance that people add-IMakefiles/Systems
to their setup unless-I
is recursive in make. There may be a better way to avoid this (e.g. tryinginclude Makefile.whatever
and falling back to tryinginclude Makefiles/Systems/Makefile.whatever
if it failed). Of course this would impact all projects with gyrokinetics. -
reporter - changed status to resolved
Fixed by PR #126
- Log in to comment
I think this is a Good Thing - it makes things easier to find, makes gs2 conform to best practices, etc, etc.
I can imagine merging with development branches being a bit of a pain. Perhaps the best approach is to plan to do this as one of the last commits before 8.1, after all the code developments have been merged?