Remove some logic from the superbuild #2469
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Superbuild cannot write to
CMAKE_INSTALL_PREFIX
during configure time. There's no guarantee that this variable is even set, or that it's a valid and writeable path if it is set (indeed, the default path is likely not writeable by the average superbuild user). Moreover, even if it is set, each package maintains its own install prefix, which may be wholly unrelated to whatever is in theCMAKE_INSTALL_PREFIX
. Finally, the superbuild doesn't define aninstall
target at all, so we cannot simply copy the file at "superbuild install time" since such a thing doesn't exist (and this certainly is not a compelling reason to change that).In spite of this seemingly bleak status quo, clients of the superbuild are much more empowered than the superbuild can inherently be, and they have access to all of the relevant information. In the case of LBANN's CI infrastructure, we do choose to install all of the dependencies under a common prefix, so we can manually copy this file over to that prefix any time after configuration has completed.
As the last bit of cleanup, I removed a message about python something or another that's LBANN's problem and should go in LBANN's CMake, not the superbuild's (the message had nothing to do with interactions with or among any of the packages known to the superbuild, and therefore it is irrelevant to the goals of the superbuild system). Also, as far as I know, CNPY has no dependence on Python or the
numpy
python module, so I also culled that message, also believing it to be irrelevant and/or erroneous (LBANN's dependence (or not) onnumpy
is a concern for the LBANN project and not the superbuild as it is not a package manager).