c++ - A Module mode failure prevents Config mode from finding the package - how to fix it? - Stack Overflow

admin管理员组

文章数量:1025244

I am building a C++ project on Windows 10 using CMake. The project links to the PCL library and to my own package pcview, both of which in turn depend on GLEW. Incidentally, PCL shouldn't actually use GLEW because the visualization module was not built. I have PCL, pcview, GLEW and all other packages set up on my computer in such a way that find_package can easily find them in the Config mode.

project ---> PCL
   |          |
   |          |
   v          v
 pcview ---> GLEW

However, when processing the project's src/CMakeLists.txt:

1. find_package( PCL REQUIRED )
2. find_package( pcview REQUIRED )
3. ...

it outputs an error:

CMake Error at D:/CMake/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
Call Stack (most recent call first):
  D:/CMake/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  D:/packages/PCL/cmake/Modules/FindGLEW.cmake:38 (find_package_handle_standard_args)
  D:/CMake/share/cmake-3.30/Modules/CMakeFindDependencyMacro.cmake:75 (find_package)
  D:/packages/pcview/cmake/pcview-config.cmake:28 (find_dependency)
  src/CMakeLists.txt:2 (find_package)

I have found out that PCL itself has a FindGLEW.cmake module, so when my pcview-config.cmake calls find_dependency( GLEW ) (a variant of find_package), the search proceeds in the Module mode first. Had that mode just silently failed, the fallback Config mode would have found GLEW without any issues. Instead, the FindGLEW.cmake provided by PCL fails to find it and calls find_package_handle_standard_args, which terminates completely with the error shown above.

Am I doing anything in the wrong way? What is the most healthy way to get CMake to find the package?

Of course I could just delete PCL's FindGLEW.cmake, or force the Config mode manually, or do some other ugly workaround. But I assume PCL is set-up in a healthy way, which means the problem lies on my end. I would like to know how to connect everything together in the most clean and professional way.

---

I'm pretty sure these are irrelevant, but somebody is going to ask anyway, so here are my CMake files.

Top CMakeLists.txt:

cmake_minimum_required( VERSION 3.12...3.30 FATAL_ERROR )

project( pcl-pcview VERSION 1.0 )

set( CMAKE_CXX_STANDARD 20 )
set( CMAKE_CXX_STANDARD_REQUIRED True )

add_subdirectory( src )

src/CMakeLists.txt:

find_package( PCL REQUIRED )
find_package( pcview REQUIRED )

set( LIBS ${PCL_LIBRARIES} pcview::pcview )


add_executable( pcl-pcview main.cxx )

target_link_libraries( pcl-pcview PRIVATE ${LIBS} )

I am building a C++ project on Windows 10 using CMake. The project links to the PCL library and to my own package pcview, both of which in turn depend on GLEW. Incidentally, PCL shouldn't actually use GLEW because the visualization module was not built. I have PCL, pcview, GLEW and all other packages set up on my computer in such a way that find_package can easily find them in the Config mode.

project ---> PCL
   |          |
   |          |
   v          v
 pcview ---> GLEW

However, when processing the project's src/CMakeLists.txt:

1. find_package( PCL REQUIRED )
2. find_package( pcview REQUIRED )
3. ...

it outputs an error:

CMake Error at D:/CMake/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
Call Stack (most recent call first):
  D:/CMake/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  D:/packages/PCL/cmake/Modules/FindGLEW.cmake:38 (find_package_handle_standard_args)
  D:/CMake/share/cmake-3.30/Modules/CMakeFindDependencyMacro.cmake:75 (find_package)
  D:/packages/pcview/cmake/pcview-config.cmake:28 (find_dependency)
  src/CMakeLists.txt:2 (find_package)

I have found out that PCL itself has a FindGLEW.cmake module, so when my pcview-config.cmake calls find_dependency( GLEW ) (a variant of find_package), the search proceeds in the Module mode first. Had that mode just silently failed, the fallback Config mode would have found GLEW without any issues. Instead, the FindGLEW.cmake provided by PCL fails to find it and calls find_package_handle_standard_args, which terminates completely with the error shown above.

Am I doing anything in the wrong way? What is the most healthy way to get CMake to find the package?

Of course I could just delete PCL's FindGLEW.cmake, or force the Config mode manually, or do some other ugly workaround. But I assume PCL is set-up in a healthy way, which means the problem lies on my end. I would like to know how to connect everything together in the most clean and professional way.

---

I'm pretty sure these are irrelevant, but somebody is going to ask anyway, so here are my CMake files.

Top CMakeLists.txt:

cmake_minimum_required( VERSION 3.12...3.30 FATAL_ERROR )

project( pcl-pcview VERSION 1.0 )

set( CMAKE_CXX_STANDARD 20 )
set( CMAKE_CXX_STANDARD_REQUIRED True )

add_subdirectory( src )

src/CMakeLists.txt:

find_package( PCL REQUIRED )
find_package( pcview REQUIRED )

set( LIBS ${PCL_LIBRARIES} pcview::pcview )


add_executable( pcl-pcview main.cxx )

target_link_libraries( pcl-pcview PRIVATE ${LIBS} )

• c++
• windows
• cmake
• point-cloud-library
• glew

Share Improve this question Follow edited Dec 20, 2024 at 22:17 Christoph Rackwitz 16k55 gold badges3939 silver badges5151 bronze badges asked Nov 18, 2024 at 15:52 AdayahAdayah 23644 silver badges88 bronze badges 3

• 2 Can you add message(CMAKE_MODULE_PATH="${CMAKE_MODULE_PATH}") before and after the find_package(PCL REQUIRED) call? PCL might change this variable; as a consequence PCL's FindGLEW.cmake is used. If this is the case, you could either reset CMAKE_MODULE_PATH to the original value after PCL was found, or switch the find_package calls for PCL and pcview. – IBitMyBytes Commented Nov 18, 2024 at 16:10
• @IBitMyBytes PCL sets this variable indeed and clearing it solves the issue - thanks! But this also feels like a slight workaround and I strongly wish to locate the deeper source of the issue. My thoughts are, is it not a bad practice on PCL's part to terminate the search when FindGLEW fails, without giving the Config mode a chance? The same situation could have happened with PCL alone (i.e. sans pcview) if I'm not mistaken - GLEW is out there, ready to be found, but a badly written FindGLEW prevents it from happening? Or is it something else? – Adayah Commented Nov 19, 2024 at 8:13
• 1 PCL's FindGLEW.cmake has actually been removed 2 months ago, so future PCL releases will not have that any more. That version was seemingly equivalent to the one from CMake 3.13. The FindGLEW.cmake from newer CMake versions looks quite different. So seems like PCL's FindGLEW.cmake was outdated. – IBitMyBytes Commented Nov 19, 2024 at 9:50

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 3

Here again as a proper answer: You can add message(CMAKE_MODULE_PATH="${CMAKE_MODULE_PATH}") before and after the find_package(PCL REQUIRED) call to find out if PCL changes this variable; as a consequence PCL's FindGLEW.cmake is used. One option is to reset CMAKE_MODULE_PATH to the original value after PCL was found:

set(original_cmake_module_path "${CMAKE_MODULE_PATH}")
find_package( PCL REQUIRED )
set(CMAKE_MODULE_PATH "${original_cmake_module_path}")
find_package( pcview REQUIRED )

Or switch the find_package calls for PCL and pcview.

PCL's FindGLEW.cmake has actually been removed 2 months ago, so future PCL releases will not have that any more. That version was seemingly equivalent to the one from CMake 3.13. The FindGLEW.cmake from newer CMake versions looks quite different. So seems like PCL's FindGLEW.cmake was outdated.

I am building a C++ project on Windows 10 using CMake. The project links to the PCL library and to my own package pcview, both of which in turn depend on GLEW. Incidentally, PCL shouldn't actually use GLEW because the visualization module was not built. I have PCL, pcview, GLEW and all other packages set up on my computer in such a way that find_package can easily find them in the Config mode.

project ---> PCL
   |          |
   |          |
   v          v
 pcview ---> GLEW

However, when processing the project's src/CMakeLists.txt:

1. find_package( PCL REQUIRED )
2. find_package( pcview REQUIRED )
3. ...

it outputs an error:

CMake Error at D:/CMake/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
Call Stack (most recent call first):
  D:/CMake/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  D:/packages/PCL/cmake/Modules/FindGLEW.cmake:38 (find_package_handle_standard_args)
  D:/CMake/share/cmake-3.30/Modules/CMakeFindDependencyMacro.cmake:75 (find_package)
  D:/packages/pcview/cmake/pcview-config.cmake:28 (find_dependency)
  src/CMakeLists.txt:2 (find_package)

I have found out that PCL itself has a FindGLEW.cmake module, so when my pcview-config.cmake calls find_dependency( GLEW ) (a variant of find_package), the search proceeds in the Module mode first. Had that mode just silently failed, the fallback Config mode would have found GLEW without any issues. Instead, the FindGLEW.cmake provided by PCL fails to find it and calls find_package_handle_standard_args, which terminates completely with the error shown above.

Am I doing anything in the wrong way? What is the most healthy way to get CMake to find the package?

Of course I could just delete PCL's FindGLEW.cmake, or force the Config mode manually, or do some other ugly workaround. But I assume PCL is set-up in a healthy way, which means the problem lies on my end. I would like to know how to connect everything together in the most clean and professional way.

---

I'm pretty sure these are irrelevant, but somebody is going to ask anyway, so here are my CMake files.

Top CMakeLists.txt:

cmake_minimum_required( VERSION 3.12...3.30 FATAL_ERROR )

project( pcl-pcview VERSION 1.0 )

set( CMAKE_CXX_STANDARD 20 )
set( CMAKE_CXX_STANDARD_REQUIRED True )

add_subdirectory( src )

src/CMakeLists.txt:

find_package( PCL REQUIRED )
find_package( pcview REQUIRED )

set( LIBS ${PCL_LIBRARIES} pcview::pcview )


add_executable( pcl-pcview main.cxx )

target_link_libraries( pcl-pcview PRIVATE ${LIBS} )

I am building a C++ project on Windows 10 using CMake. The project links to the PCL library and to my own package pcview, both of which in turn depend on GLEW. Incidentally, PCL shouldn't actually use GLEW because the visualization module was not built. I have PCL, pcview, GLEW and all other packages set up on my computer in such a way that find_package can easily find them in the Config mode.

project ---> PCL
   |          |
   |          |
   v          v
 pcview ---> GLEW

However, when processing the project's src/CMakeLists.txt:

1. find_package( PCL REQUIRED )
2. find_package( pcview REQUIRED )
3. ...

it outputs an error:

CMake Error at D:/CMake/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
Call Stack (most recent call first):
  D:/CMake/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  D:/packages/PCL/cmake/Modules/FindGLEW.cmake:38 (find_package_handle_standard_args)
  D:/CMake/share/cmake-3.30/Modules/CMakeFindDependencyMacro.cmake:75 (find_package)
  D:/packages/pcview/cmake/pcview-config.cmake:28 (find_dependency)
  src/CMakeLists.txt:2 (find_package)

I have found out that PCL itself has a FindGLEW.cmake module, so when my pcview-config.cmake calls find_dependency( GLEW ) (a variant of find_package), the search proceeds in the Module mode first. Had that mode just silently failed, the fallback Config mode would have found GLEW without any issues. Instead, the FindGLEW.cmake provided by PCL fails to find it and calls find_package_handle_standard_args, which terminates completely with the error shown above.

Am I doing anything in the wrong way? What is the most healthy way to get CMake to find the package?

Of course I could just delete PCL's FindGLEW.cmake, or force the Config mode manually, or do some other ugly workaround. But I assume PCL is set-up in a healthy way, which means the problem lies on my end. I would like to know how to connect everything together in the most clean and professional way.

---

I'm pretty sure these are irrelevant, but somebody is going to ask anyway, so here are my CMake files.

Top CMakeLists.txt:

cmake_minimum_required( VERSION 3.12...3.30 FATAL_ERROR )

project( pcl-pcview VERSION 1.0 )

set( CMAKE_CXX_STANDARD 20 )
set( CMAKE_CXX_STANDARD_REQUIRED True )

add_subdirectory( src )

src/CMakeLists.txt:

find_package( PCL REQUIRED )
find_package( pcview REQUIRED )

set( LIBS ${PCL_LIBRARIES} pcview::pcview )


add_executable( pcl-pcview main.cxx )

target_link_libraries( pcl-pcview PRIVATE ${LIBS} )

• c++
• windows
• cmake
• point-cloud-library
• glew

Share Improve this question Follow edited Dec 20, 2024 at 22:17 Christoph Rackwitz 16k55 gold badges3939 silver badges5151 bronze badges asked Nov 18, 2024 at 15:52 AdayahAdayah 23644 silver badges88 bronze badges 3

• 2 Can you add message(CMAKE_MODULE_PATH="${CMAKE_MODULE_PATH}") before and after the find_package(PCL REQUIRED) call? PCL might change this variable; as a consequence PCL's FindGLEW.cmake is used. If this is the case, you could either reset CMAKE_MODULE_PATH to the original value after PCL was found, or switch the find_package calls for PCL and pcview. – IBitMyBytes Commented Nov 18, 2024 at 16:10
• @IBitMyBytes PCL sets this variable indeed and clearing it solves the issue - thanks! But this also feels like a slight workaround and I strongly wish to locate the deeper source of the issue. My thoughts are, is it not a bad practice on PCL's part to terminate the search when FindGLEW fails, without giving the Config mode a chance? The same situation could have happened with PCL alone (i.e. sans pcview) if I'm not mistaken - GLEW is out there, ready to be found, but a badly written FindGLEW prevents it from happening? Or is it something else? – Adayah Commented Nov 19, 2024 at 8:13
• 1 PCL's FindGLEW.cmake has actually been removed 2 months ago, so future PCL releases will not have that any more. That version was seemingly equivalent to the one from CMake 3.13. The FindGLEW.cmake from newer CMake versions looks quite different. So seems like PCL's FindGLEW.cmake was outdated. – IBitMyBytes Commented Nov 19, 2024 at 9:50

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 3

Here again as a proper answer: You can add message(CMAKE_MODULE_PATH="${CMAKE_MODULE_PATH}") before and after the find_package(PCL REQUIRED) call to find out if PCL changes this variable; as a consequence PCL's FindGLEW.cmake is used. One option is to reset CMAKE_MODULE_PATH to the original value after PCL was found:

set(original_cmake_module_path "${CMAKE_MODULE_PATH}")
find_package( PCL REQUIRED )
set(CMAKE_MODULE_PATH "${original_cmake_module_path}")
find_package( pcview REQUIRED )

Or switch the find_package calls for PCL and pcview.

PCL's FindGLEW.cmake has actually been removed 2 months ago, so future PCL releases will not have that any more. That version was seemingly equivalent to the one from CMake 3.13. The FindGLEW.cmake from newer CMake versions looks quite different. So seems like PCL's FindGLEW.cmake was outdated.

本文标签： cA Module mode failure prevents Config mode from finding the packagehow to fix itStack Overflow