Name |
Last commit
|
Last update |
---|---|---|
src | ||
tests | ||
.HEADER | ||
.gitignore | ||
CMakeLists.txt | ||
CONVENTIONS | ||
COPYING | ||
README.md | ||
api.doxygen | ||
git.git-authors | ||
libgit2.pc.in | ||
waf | ||
wscript |
FindPkgConfig obviously uses pkg-config's output for setting convenient variables such as <PREFIX>_LIBRARIES or <PREFIX>_INCLUDE_DIRS. It also sets <PREFIX>_FOUND to 1 if <PREFIX> module exists. So why checking for SQLITE3_FOUND is better than (SQLITE3_LIBRARIES AND SQLITE3_INCLUDE_DIRS)? Apart from obvious readability factor, latter condition has strong assumption that both variables are filled with appropriate paths, which is unjustifiable unless you add another assumptions... pkg-config by default strips -I/usr/include from Cflags and -L/usr/lib from Libs if some environment variables are not set, PKG_CONFIG_ALLOW_SYSTEM_CFLAGS and PKG_CONFIG_ALLOW_SYSTEM_LIBS respectively. This behavior is sane, because it prevents polluting the compilation and linking commands with superfluous entries. In debian SQLITE3_INCLUDE_DIRS is empty for instance. Remark for developers: Always check commands invoked by CMake after changing CMakeLists.txt. VERBOSE=1 cmake --build .
Name |
Last commit
|
Last update |
---|---|---|
src | Loading commit data... | |
tests | Loading commit data... | |
.HEADER | Loading commit data... | |
.gitignore | Loading commit data... | |
CMakeLists.txt | Loading commit data... | |
CONVENTIONS | Loading commit data... | |
COPYING | Loading commit data... | |
README.md | Loading commit data... | |
api.doxygen | Loading commit data... | |
git.git-authors | Loading commit data... | |
libgit2.pc.in | Loading commit data... | |
waf | Loading commit data... | |
wscript | Loading commit data... |