Refactor CMake configuration #1502
This is an effort to refactor the CMake configuration by moving code from the main configuration file into utility functions and include files.
Over time this main file has grown to almost 2000 lines, up to the point where it is hard to see what it is actually doing, even for people who originally worked on it. This brings it back down to about 720 lines.
Not perfect, it's still a beast, but hopefully a step in the right direction.
@rbberger (Temple U)
By submitting this pull request, I agree, that my contribution will be included in LAMMPS and redistributed under either the GNU General Public License version 2 (GPL v2) or the GNU Lesser General Public License version 2.1 (LGPL v2.1).
Post Submission Checklist
Please check the fields below as they are completed after the pull request has been submitted. Delete lines that don't apply
Further Information, Files, and Links
Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)
Jun 9, 2019
@junghans no reason, just didn't get to it yet. I wanted to get some feedback.
I'll experiment with your suggestion of moving the CMakeLists.txt to each package folder. The primary reason I did it this way is to preserve the variable scopes and keep stuff in the
don't think it is such a good idea to move cmake files into package folders. it will just needlessly scatter them. it is not like we have a hierarchical build where the build is recursing through folders to do independent builds in each of them. instead we have one "flat" build for the LAMMPS executable. it seems much more logical to me to keep all files for that in the cmake folder or a subfolder.
If we don't have a fully all-in-one
In retrospective we should create the lammps target first and just add packages to it with
this goes contrary to my experience with the various Install.py files in the lib tree. it has become a bit of a nightmare to keep them all consistent and avoid duplicated or non uniform code, especially when other developers, that maintain packages and their libraries, make changes to them, that are not consistent, since they only look at the folder that they consider themselves responsible for.