Closed elykwilliams closed 4 months ago
The issue seems to be that even though ${CMAKE_INSTALL_PREFIX}
is updated at install time, install(CODE ... )
is using the cached value from configure time to try creating the symbolic link.
It looks like other people have run into this, and was addressed in cmake 3.27 by allowing for $<INSTALL_PREFIX>
to be evaluated in install(CODE ... )
While I see no problem in not supporting this for cmake versions less than 3.27, I'm not sure currently how one would detect and handle it gracefully.
The issue seems to be that even though
${CMAKE_INSTALL_PREFIX}
is updated at install time,install(CODE ... )
is using the cached value from configure time to try creating the symbolic link.It looks like other people have run into this, and was addressed in cmake 3.27 by allowing for
$<INSTALL_PREFIX>
to be evaluated ininstall(CODE ... )
While I see no problem in not supporting this for cmake versions less than 3.27, I'm not sure currently how one would detect and handle it gracefully.
Maybe @scivision has an idea of the CMake version checks and requirements.
So something is definitely not right with the CMake CI, related to the most recent couple merges?
My comment here was largely irrelevant after I found the fix in the submitted PR.
So something is definitely not right with the CMake CI, related to the most recent couple merges?
Looking into it
This issue may be resolved, since the CI fail relates to gcc-13 on MacOS?
Description I get the following error when specifying the install prefix path at install time to a non-default location
To Reproduce
Additional information cmake version 3.22.1