Directory structure

Issue #50 resolved
David Dickinson created an issue

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)

  1. Joseph Parker

    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?

  2. David Dickinson 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
    
  3. Joseph Parker

    I think this structure is good. I also like the idea of dividing Makefiles into Makefiles/Compilers and Makefiles/Systems.

  4. David Dickinson 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 own Makefile.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. trying include Makefile.whatever and falling back to trying include Makefiles/Systems/Makefile.whatever if it failed). Of course this would impact all projects with gyrokinetics.

  5. Log in to comment