I have a few issues with installing QuEST v4 header files.
- Headers are installed to the configured destdir, not the one passed at install-time, which means the build directory needs to be re-configured at every different install path, and that if you did not specify the header install dir at all initially it will attempt to install at the system location and fail:
cmake --install build/ --prefix $HOME/quantsim/versions/v4-main
-- Install configuration: "RelWithDbgInfo"
-- Installing: /usr/local/quest/include
CMake Error at build/quest/include/cmake_install.cmake:54 (file):
file INSTALL cannot make directory "/usr/local/quest/include": No such file
or directory.
Call Stack (most recent call first):
build/quest/cmake_install.cmake:52 (include)
build/cmake_install.cmake:47 (include)
- Headers aren’t installed under
$PREFIX/include but under $PREFIX/quest/include because that seems to be their path inside the source distribution - Once installed, including headers fails as they use hard-coded
quest/include/ prefixes. This means you need both a -I$PREFIX/quest/include to find quest.h and then a -I$PREFIX so that quest.h's includes can find the other quest includes. - Once installed,
quest/include/modes.h are still requiring COMPILE_XXX to be set, but those are compile-time constants. The values set at compile-time should be exported in a header file and included along with the rest so that they are coherent with the installed binaries. I know that currently they are exported in the INTERFACE_COMPILE_DEFINITIONS in QuESTTargets.cmake but that restricts any usage to CMake projects.
I think it would be sufficient to adjust the install paths for quest headers to be under $PREFIX/include (keeping relative directories so $PREFIX/include/quest/include/*.h) and adding a quest.h.in that goes to $PREFIX/include/quest.h, that receives the configuration values and includes the previous quest.h. Or otherwise a more standard config.h.in and correcting the layout of includes.
I have a few issues with installing QuEST v4 header files.
$PREFIX/includebut under$PREFIX/quest/includebecause that seems to be their path inside the source distributionquest/include/prefixes. This means you need both a-I$PREFIX/quest/includeto findquest.hand then a-I$PREFIXso thatquest.h's includes can find the other quest includes.quest/include/modes.hare still requiringCOMPILE_XXXto be set, but those are compile-time constants. The values set at compile-time should be exported in a header file and included along with the rest so that they are coherent with the installed binaries. I know that currently they are exported in theINTERFACE_COMPILE_DEFINITIONSinQuESTTargets.cmakebut that restricts any usage to CMake projects.I think it would be sufficient to adjust the install paths for quest headers to be under
$PREFIX/include(keeping relative directories so$PREFIX/include/quest/include/*.h) and adding aquest.h.inthat goes to$PREFIX/include/quest.h, that receives the configuration values and includes the previousquest.h. Or otherwise a more standardconfig.h.inand correcting the layout of includes.