Совместимость флагов и glog

Question

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

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

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

Теперь GLog-х ABI вокруг флагов совместимы с GFlags

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

, но я не могу понять, какая версия gflags. (Который я нашел странным, потому что GLog depens на 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 и заглядываете со старого сайта хостинга Google Code. В то время, когда был поставлен вопрос, glog уже перешел в GitHub и сделал более новую версию (0.3.4). Это могло послужить причиной несовместимости.

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

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

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