关于cmake找不到库文件的问题

[Lupe]

用cmake连接一个库文件libglog.lib，在cmakelist里写find_package(lib_glog REQUIRED)，在Findlib_glog.cmake中配置好了

# Include dir
find_path(lib_glog_INCLUDE_DIR
  NAMES glog/glog.h
  PATHS $ENV{GLOG_INCLUDE_DIR}
)

# Finally the library itself
find_library(lib_glog_LIBRARY
  NAMES libglog
  PATHS $ENV{GLOG_LIBRARY}
)

message(STATUS ${lib_glog_INCLUDE_DIR} ${lib_glog_LIBRARY})

build.bat中设置好了参数GLOG_INCLUDE_DIR，GLOG_LIBRARY
可是cmake的时候就是提示lib_glog_INCLUDE_DIR-NOTFOUNDD:/cobra/program/third_party/glog-0.3.3/Debug/libglog.lib
路径肯定没有问题啊，我手动配置库都可以，就是想不通什么原因

[Lupe]

找到原因了，.cmake文件里面NAMES的文件名拼错了

[赵4老师]

lib_glog_INCLUDE_DIR-NOTFOUND D:/cobra/program/third_party/glog-0.3.3/Debug/libglog.lib 要求目录 给文件 ？

[赵4老师]

引用 1 楼 u012410577 的回复:

找到原因了，.cmake文件里面NAMES的文件名拼错了

关于自己是否适合编程的很简单的测试： 在报纸或杂志上随便找一段约1000字的文章，在Word中输入一遍。输完后再参考下面答案： A里面有10处以上文字或标点错误 B里面没有文字或标点错误并敢为此跟人打赌 C里面没有文字或标点错误并且字体和排版完全与原稿一致 D打印在半透明的纸上和原稿重叠在一起检查一模一样，且自我感觉很有成就感 A不适合编程（理由：打字准确度偏低、粗心大意） B初级程序员（理由：打字准确度很高、认真细致、自信、理解全角半角概念） C高级程序员（理由：在B的基础上理解字体和排版也是电脑打印的重要因素、但相比D还不够偏执、精益求精、结果可验证） D软件项目经理（理由：能针对项目给出令人信服的细致到极点的需求说明和典型测试用例。用户几乎挑不出毛病。专业！） 如果想从A变成B的话，到我的资源http://download.csdn.net/detail/zhao4zhong1/4084259里面下载“适合程序员的键盘练习”

[Lupe]

引用 3 楼 zhao4zhong1 的回复:

[quote=引用 1 楼 u012410577 的回复:] 找到原因了，.cmake文件里面NAMES的文件名拼错了

关于自己是否适合编程的很简单的测试： 在报纸或杂志上随便找一段约1000字的文章，在Word中输入一遍。输完后再参考下面答案： A里面有10处以上文字或标点错误 B里面没有文字或标点错误并敢为此跟人打赌 C里面没有文字或标点错误并且字体和排版完全与原稿一致 D打印在半透明的纸上和原稿重叠在一起检查一模一样，且自我感觉很有成就感 A不适合编程（理由：打字准确度偏低、粗心大意） B初级程序员（理由：打字准确度很高、认真细致、自信、理解全角半角概念） C高级程序员（理由：在B的基础上理解字体和排版也是电脑打印的重要因素、但相比D还不够偏执、精益求精、结果可验证） D软件项目经理（理由：能针对项目给出令人信服的细致到极点的需求说明和典型测试用例。用户几乎挑不出毛病。专业！） 如果想从A变成B的话，到我的资源http://download.csdn.net/detail/zhao4zhong1/4084259里面下载“适合程序员的键盘练习” [/quote]非常感谢，顺便问一个问题，我有一个第三方dll，我不想放在系统目录和程序目录下，能不能用cmake指定路径呢？

[赵4老师]

LoadLibrary The LoadLibrary function maps the specified executable module into the address space of the calling process. HINSTANCE LoadLibrary( LPCTSTR lpLibFileName // address of filename of executable module ); Parameters lpLibFileName Pointer to a null-terminated string that names the executable module (either a .DLL or .EXE file). The name specified is the filename of the module and is not related to the name stored in the library module itself, as specified by the LIBRARY keyword in the module-definition (.DEF) file. If the string specifies a path but the file does not exist in the specified directory, the function fails. When specifying a path, be sure to use backslashes (\), not forward slashes (/). If the string does not specify a path, the function uses a standard search strategy to find the file. See the Remarks for more information. Return Values If the function succeeds, the return value is a handle to the module. If the function fails, the return value is NULL. To get extended error information, call GetLastError. Remarks LoadLibrary can be used to map a DLL module and return a handle that can be used in GetProcAddress to get the address of a DLL function. LoadLibrary can also be used to map other executable modules. For example, the function can specify an .EXE file to get a handle that can be used inFindResource orLoadResource. Do not use LoadLibrary to "run" a .EXE file. If the module is a DLL not already mapped for the calling process, the system calls the DLL's DllMain function with the DLL_PROCESS_ATTACH value. If the DLL's entry-point function does not return TRUE, LoadLibrary fails and returns NULL. It is not safe to call LoadLibrary from DllMain. For more information, see the Remarks section in DllMain. Module handles are not global or inheritable. A call to LoadLibrary by one process does not produce a handle that another process can use — for example, in calling GetProcAddress. The other process must make its own call to LoadLibrary for the module before calling GetProcAddress. If no filename extension is specified in the lpLibFileName parameter, the default library extension .DLL is appended. However, the filename string can include a trailing point character (.) to indicate that the module name has no extension. When no path is specified, the function searches for loaded modules whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file in the following sequence: The directory from which the application loaded. The current directory. Windows 95 and Windows 98: The Windows system directory. Use theGetSystemDirectory function to get the path of this directory. Windows NT: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32. Windows NT: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM. The Windows directory. Use theGetWindowsDirectory function to get the path of this directory. The directories that are listed in the PATH environment variable. The first directory searched is the one directory containing the image file used to create the calling process (for more information, see the CreateProcess function). Doing this allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable. The Visual C++ compiler supports a syntax that enables you to declare thread-local variables: _declspec(thread). If you use this syntax in a DLL, you will not be able to load the DLL explicitly using LoadLibrary or LoadLibraryEx. If your DLL will be loaded explicitly, you must use the thread local storage functions instead of _declspec(thread). Windows 95: If you are using LoadLibrary to load a module that contains a resource whose numeric identifier is greater than 0x7FFF, LoadLibrary fails. Windows CE: Two different modules cannot have the same filename, given that the extensions are different. These effectively have the same "module" name. For example, if LoadLibrary is made on "Sample.cpl", the operating system will not load Sample.cpl, but instead will again load Sample.dll. A similar limitation exists for modules with the same name but residing in different directories. For example, if LoadLibrary is called on "\\Windows\Sample.dll", and then LoadLibrary is called on "\\MyDir\Sample.dll", "\\Windows\Sample.dll" will simply be reloaded. A search path to the executable module cannot be specified. Unless the full path to the module is given, Windows CE will search the following path for the module: The root directory of the PC Card RAM expansion card, if one exists. The windows directory (\Windows). The root directory (\). QuickInfo Windows NT: Requires version 3.1 or later. Windows: Requires Windows 95 or later. Windows CE: Requires version 1.0 or later. Header: Declared in winbase.h. Import Library: Use kernel32.lib. Unicode: Implemented as Unicode and ANSI versions on Windows NT. See Also Dynamic-Link Libraries Overview, Dynamic-Link Library Functions, DllMain,FindResource, FreeLibrary, GetProcAddress,GetSystemDirectory,GetWindowsDirectory, LoadLibraryEx,LoadResource

[bpq1971618]

cmake的包括找不到加载文件 The CXX compiler identification is MSVC 16.0.30319.1 The C compiler identification is MSVC 16.0.30319.1 Detecting CXX compiler ABI info Detecting CXX compiler ABI info - done Detecting CXX compile features Detecting CXX compile features - done Detecting C compiler ABI info Detecting C compiler ABI info - done CMake Error at CMakeLists.txt:62 (include): include could not find load file: cmake/OpenCVUtils.cmake CMake Error at CMakeLists.txt:64 (ocv_clear_vars): Unknown CMake command "ocv_clear_vars". Configuring incomplete, errors occurred! See also "F:/opencv/build/opencvbuild/CMakeFiles/CMakeOutput.log".