The main CMakeLists.txt wants to install FindLibRaw.cmake always into ${CMAKE_ROOT}/Modules. This might be the right place for system libraries, but if I choose a different installation prefix (via CMAKE_INSTALL_PREFIX) like my home directory, the install will fail due to missing root privilidges to write in /usr/share/cmake/Modules. The CMakeLists.txt should never install anything outside of CMAKE_INSTALL_PREFIX.

But there is a second problem. Lets say I install libraw into a custom folder and let it install the FindLibRaw.cmake file in the system path. Then the installation will not work. The actual install prefix is NOT configured into FindLibRaw.cmake, which means that CMake will only use the default search methods and search paths and cannot find my custom install path. (Unless I specify a search path prior to using find_package(libraw), but that contradicts the usefulness of having FindLibRaw.cmake in the first place).

The preferred CMake approach to have libraries in custom paths is to use a LibRawConfig.cmake (take a look at OpenCVConfig.cmake as an example) which is configured to contain all the right paths and will be placed into the installation prefix folder, much like a pc-file.

Speaking of which, if anyone wants to use pkg-config for libraw built and installed using cmake into a custom path, it is broken. The file cmake/data/libraw.pc.cmake (likewise libraw_r.pc.cmake) contains the wrong include path. It starts with 'includedir=${prefix}/include/libraw'. Then the flags are defined as 'CFlags: -I${includedir}/libraw' which actually is '${prefix}/include/libraw/libraw', which does not exist. So unless the include files happen to be in the compilers default search path, it cannot find any includes. The includedir should only read '${prefix}/include' and the flags should be '-I${includedir}'.

The libraw.pc.in has a similar problem, where the include flag is '${includedir}/libraw'. This prevents '#include "libraw/libraw.h"' unless the base folder is in the compilers default search path anyway.

Last but not least, the LibRaw object does not provide a custom copy constructor. The default copy constructor will however break the object by copying pointers, which likely leads to a segfault when using the destructor on the second copy or using one copy after destructing the other. The copy constructor should either be provided explicitly (proper deep copy) or forbidden explicitly (private and not implemented). The same goes for copy assignment.