All external dependencies in QZXingNu are managed via CMake's find_package(…) mechanism, with the exception of ZXing-C++, which is included in a sub-directory (see). The ZXing-C++ library is provided in that subdirectory at the time of a Git checkout via the Git submodule mechanism.
Wouldn't it be more uniform and also better to also use find_package(ZXing REQUIRED) for that dependency in CMakeLists.txt? That's possible, as ZXing-C++ provides such a package (I tried it). People could then easily have a source layout with each repository in its own directory, all only connected via CMake's find_package(…) mechanism.
An issue might be that QZXingNu depends on a particular version of ZXing-C++ and they don't seem to expose a version in the package (at least for me find_package(ZXing 1.0.8 REQUIRED) failed, telling that the version of the installed ZXing-C++ package was unknown). But then we could ask them to provide that kind of information in their CMake package.
All external dependencies in QZXingNu are managed via CMake's
find_package(…)
mechanism, with the exception of ZXing-C++, which is included in a sub-directory (see). The ZXing-C++ library is provided in that subdirectory at the time of a Git checkout via the Git submodule mechanism.Wouldn't it be more uniform and also better to also use
find_package(ZXing REQUIRED)
for that dependency inCMakeLists.txt
? That's possible, as ZXing-C++ provides such a package (I tried it). People could then easily have a source layout with each repository in its own directory, all only connected via CMake'sfind_package(…)
mechanism.An issue might be that QZXingNu depends on a particular version of ZXing-C++ and they don't seem to expose a version in the package (at least for me
find_package(ZXing 1.0.8 REQUIRED)
failed, telling that the version of the installed ZXing-C++ package wasunknown
). But then we could ask them to provide that kind of information in their CMake package.