Closed wavefunction91 closed 9 months ago
yes, of course https://github.com/ValeevGroup/tiledarray/pull/404#discussion_r1208030129 is all wrong ... I missed the uses of TILEDARRAY_INSTALL_*
dirs in TA's own CMakeLists.txt
removed unused instances of TILEDARRAY_INSTALL_*
, good to go
FWIW - it might be worth adding a unit test for this: I check both install + discover and subproject builds in
GauXC
,ExchCXX
,MACIS
, etc (since there's a butterfly effect in changingCMakeLists.txt
, these tests ensure that we don't regress expected behaviour) . If you think that's worth it for TA, I'll add an issue and add it when I get some free time.
of course this would be good. Subproject builds are already tested at the top of VG (i.e. (https://github.com/ValeevGroup/mpqc4), [MPQC
]) but need minimal subproject build anyway to avoid interaction with existing cmake state
As I mentioned in the PR discsussion, #404 breaks install as
CMAKE_INSTALL_XYZ
are not set until one of the proper CMakeXYZInstallDirs
is included.To see the offending behaviour, simply add the following likes
CMakeLists.txt
With a basic
cmake
invocationBehaviour before (incorrect)
Behaviour after (correct)
Assuming that
GNUInstallDirs
is the expected default (which was the case before #404, only hardcoded), this PR resolves the expected behaviour. N.B. Installs are currently broken without this change (unless a user manually specifies all theCMAKE_INSTALL_XYZ
variables by hand.FWIW - it might be worth adding a unit test for this: I check both install + discover and subproject builds in
GauXC
,ExchCXX
,MACIS
, etc (since there's a butterfly effect in changingCMakeLists.txt
, these tests ensure that we don't regress expected behaviour) . If you think that's worth it for TA, I'll add an issue and add it when I get some free time.