- edited description
CMake Installation -- FindUPCXX.cmake vs. UPCXXConfig.cmake
I am wondering why UPC++ installs both a FindUPCXX.cmake and UPCXXConfig.cmake. I realize that UPCXXConfig.cmake just contains: include(${CMAKE_CURRENT_LIST_DIR}/FindUPCXX.cmake)
. Standard CMake practices are such that a package that installs via CMake, provides a <PackageName>Config.cmake
(or <PackageName>-config.cmake
) for find_package(<PackageName>)
and a package that does not use CMake uses a Find<PackageName>.cmake
. And the default CMake behavior is to search for both Find<PackageName>.cmake
and <PackageName>Config.cmake
so, at a minimum, providing both is redundant.
However, if you read the details of find_package in the CMake documentation, you will find there exist an options for find_package(<PackageName> MODULE)
and a CMAKE_FIND_PACKAGE_PREFER_CONFIG
variable that allow for specification for whether the Find<PackageName>.cmake
and <PackageName>Config.cmake
are preferred (or exclusively searched for) so, by providing both, the UPC++ installation at both is seemingly making it slightly more complicated for a package to provide it’s own FindUPCXX.cmake
, if so desired, without any clear reason, e.g.:
If a package provided it’s own FindUPCXX.cmake
, this would find the UPC++ installed version instead of their own:
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${PROJECT_SOURCE_DIR}/cmake/Modules)
# ...
find_package(UPCXX MODULE)
while this would find their own:
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake/Modules ${CMAKE_MODULE_PATH})
# ...
find_package(UPCXX MODULE)
but a project may have a reason for keeping the ${CMAKE_MODULE_PATH}
before their local module file and there is nothing can be done in this situation except something like:
set(ORIG_MODULE_PATH ${CMAKE_MODULE_PATH})
# temporarily change to work-around UPC++
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake/Modules ${ORIG_MODULE_PATH})
find_package(UPCXX MODULE)
# revert to desired setup
set(CMAKE_MODULE_PATH ${ORIG_MODULE_PATH} ${PROJECT_SOURCE_DIR}/cmake/Modules)
Comments (6)
-
reporter -
-
assigned issue to
- changed version to 2019.9.0 release
Assigning to @Mathias Jacquelin for comment.
-
assigned issue to
-
@Jonathan Madsen , I would like to thank you for your observation. I chose to do it this way because I had originally written a
FindUPCXX.cmake
file and realized that I also needed a `UPCXXConfig.cmake` file to distribute UPC++ properly. I was unfortunately unaware of the implications that you mention. I propose that we address this issue in the next release by putting the content of theFindUPCXX.cmake
file directly into theUPCXXConfig.cmake
and discard theFindUPCXX.cmake
file.Thank you very much for bringing up the issue.
-
Proposed solution in pull request #142
-
reporter Yea no problem, I am re-working the CMake for a project that uses UPCXX and noticed it. I have written a fair share of cmake build systems so I suggested a couple of potential improvements in the PR. The only key one there would be the bit about the
target_compile_options(UPCXX::upcxx INTERFACE $<$<COMPILE_LANGUAGE:CXX>:${UPCXX_COMPILE_OPTIONS}>)
because that ensures targets that include C code don’t get passed C++ compiler flags if it links toUPCXX::upcxx
-
- changed status to resolved
issue
#282: Improve installed CMake package filesRename FindUPCXX.cmake to UPCXXConfig.cmake fixes issue
#282→ <<cset 0cbbf75c1929>>
- Log in to comment