QMCPACK
Add script to build, test and install real and complex versions of QMCPACK at the same time
Please review the developer documentation on the wiki of this project that contains help and requirements.
Proposed changes
Describe what this PR changes and why. If it closes an issue, link to it here with a supported keyword.
This fixes #3151
This uses CMake's externalproject_add to build, test and install qmcpack with both -DQMC_COMPLEX=0 and -DQMC_COMPLEX=1. Any arguments passed on the command line are passed to both builds. To build, change cmake [options] <path-to-source> to cmake [options] <path-to-source>/superbuild.
Ctest is configured with two tests, one for the real build and another for the complex build. Passing arguments is proving to be challenging. By default unit tests are run. To change arguments set the environment variable TEST_ARGUMENTS
TESTS_ARGUMENTS="-R short -LE unstable" ctest --verbose
The install target copies all executables from the real build along with qmcpack_complex and qmcpack_complex.settings from the complex build.
What type(s) of changes does this code introduce?
Delete the items that do not apply
- New feature
- Build related changes
Does this introduce a breaking change?
- No
What systems has this change been tested on?
Ubuntu 20.04
Checklist
Update the following with a yes where the items apply. If you're unsure about any of them, don't hesitate to ask. This is simply a reminder of what we are going to look for before merging your code.
- Yes. This PR is up to date with current the current state of 'develop'
- n/a. Code added or changed in the PR has been clang-formatted
- No. This PR adds tests to cover any new code, or to catch a bug that is being fixed
- Yes. Documentation has been added (if appropriate)
I originally wrote this as a separate repository that fetched the qmcpack repo. https://github.com/quantumsteve/qmcpack_superbuild
I think having everything in the same repo will make it easier to keep everything working and up-to-date.
@prckent I tried to address your first two comments.
With respect to cdash, I think it would current do two submissions accumulating the results?. I could copy the CDASH information into unifiedbuild/CMakeLists.txt so the two upstream (real and complex build) tests also report, but doubt that's useful information.
(I am in report writing mode currently, but poke me if you want/need this looked at. I don't think that there is much risk of a merge conflict arising.)
