Совместимость с Gflags и Glog

Question

Я хотел создать gflags и glog в моем проекте. Ниже вы видите код. Я компилирую почти нормально, но из-за некоторой ошибки совместимости у меня появляются различные фатальные ошибки, в зависимости от того, какую версию gflags я пытаюсь использовать в какой версии glog. Как показано, мне преподносят ошибку

./src/glog/stl_logging.h:56:11: fatal error: 'ext/slist' file not found
# include <ext/slist>" )

Я нашел гордое сообщение

Теперь ABI вокруг флагов glog совместимы с gflags

на сайте, объявляя glog 0.3.3 https://code.google.com/p/google-glog/

но я не могу понять, какая версия gflags. (что я нашел странным, потому что glog зависит от gflags)

# Install GFlags
ExternalProject_Add(
    GFlagsLib
    URL https://github.com/gflags/gflags/archive/master.zip
    CONFIGURE_COMMAND <SOURCE_DIR>/configure  --prefix=<INSTALL_DIR>
    )
ExternalProject_Get_Property(GFlagsLib install_dir)
include_directories(${install_dir}/include)
set(GFLAGS_LIBRARIES ${install_dir}/lib/libgflags.${link_library_suffix})
set(GFLAGS_PREFIX ${install_dir})

# Install GLog
ExternalProject_Add(
    GLogLib
    URL http://google-glog.googlecode.com/files/glog-0.3.3.tar.gz
    CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --with-gflags=${GFLAGS_PREFIX}
    )
ExternalProject_Get_Property(GLogLib install_dir)

Answer 1

Я знаю, что это старый вопрос, но я решил дать ему шанс, если у людей из будущего возникнут аналогичные вопросы. Во-первых, похоже, что вы получаете gflags из GitHub и glog со старого хостинг-сайта Google Code. В то время, когда вопрос был опубликован, glog уже перешел на GitHub и выпустил более новую версию (0.3.4). Это могло быть причиной несовместимости.

Далее пока CMake's ExternalProject_Add() функция полезна для управления пакетами, часто приводит к необходимости развертывать собственную версию find_package() с помощью ExternalProject_Get_Property() определить местоположение заголовка и библиотеки для последующих целей. Как видите, и у меня одни и те же головные боли, это может стать довольно хрупким.

Недавно я начал использовать менеджер пакетов Hunter для обработки зависимостей в проектах C++ и могу рекомендовать его как отличную альтернативу. Я использовал его в своих собственных проектах для gflags, glog и других библиотек. Каждый релиз Hunter блокирует версии пакета (посредством вызова HunterGate() с соответствующими аргументами), чтобы помочь обеспечить успешную и воспроизводимую сборку.

Возможно, благодаря конкуренции со стороны Python (pip) и Node.js (npm), управление пакетами C++ в целом в последнее время значительно улучшилось. Вам также следует взглянуть на Conan.io (из JFrog) и Buckaroo (из Facebook), если вам интересно.