Conan: менеджер зависимостей для C/C++ / forpes.ru

Главная
Conan: менеджер зависимостей для C/C++

Conan: менеджер зависимостей для C/C++ +36

27.11.2017 18:45

ZaMaZaN4iK 64 9400 Источник

Здравствуйте. Сегодня речь пойдёт про Conan — современный менеджер зависимостей для C/C++. Если Вы уже активно работаете с ним, то навряд ли найдёт что-нибудь новое для себя. Иначе — прошу под кат.

Зачем нужен менеджер зависимостей

Если Вы пользователь Linux-based дистрибутива или macOS, то для Вас скорее всего не является проблемой подтянуть какую-то нужную зависимость — в дистрибутивах скорее всего есть нужный Вам <library_name>-dev пакет. Но если Вы пользователь Windows, то думаю часто сталкивались с проблемой, как же подтянуть в проект какую-бы то ни было зависимость. Хорошо, если сторонняя библиотека header-only — нужно только скопировать заголовочные файлы в нужное и начинать использовать. Но обычно библиотеки нужно собирать (а так как в С++ зоопарк, то это зачастую не так просто сделать), потом разместить скомпилированную библиотеку в нужное Вам место. И только после этого Вы сможете её использовать.

К тому же не забудем про то, что мы должны компилировать библиотеки желательно одним компиляторам, не забывать о совместимости ABI и т.д. Да и сама компиляция занимает очень много времени (привет Boost). Многовато для обычных смертных, не находите? А тем временем некоторые люди просто используют pip, npm, cargo, maven и т.д. и экономят себе много нервов.

Предыдущие попытки

Хотелось бы иметь аналог npm, но для C++. Чтобы буквально одной командой подтягивать нужную Вам зависимость в проект и не знать головной боли.

Ранее уже были попытки создания такого средства для C++. Может, некоторые из Вас помнят такую вещь как biicode. Он, к сожалению, приказал долго жить. Здесь можете ознакомиться с причиной смерти пациента. Интересный факт: создатели Conan и biicode — примерно одни и те же люди. Возникает резонный вопрос: не повторит ли Conan судьбу biicode?

Есть и современные альтернативы Conan. Из наиболее известных: vcpkg, hunter, buckaroo.

Как установить?

Для начала нужно установить сам Conan. Есть множество путей для этого: Ваш любимый пакетный менеджер, pip, brew. Также имеются бинарные сборки под Ubuntu/Debian и Windows. Сами авторы рекомендуют использовать установку через pip. Если Вам эти способы не нравятся, то Вы всегда можете собрать сами из исходного кода.

Особенности

Conan отслеживает за Вас такие вещи как: компилятор, версия компилятора, операционная система, разрядность ОС, тип сборки (Release/Debug), версия стандартной библиотеки. Используя данные параметры Conan пытается найти собранную версию под Ваши конфигурацию. Если повезёт, то в репозитории найдётся уже собранная версия и Вам не придётся ничего компилировать.

Если же Вам не повезло и под сочетание Ваших ОС/компилятора/и т.д. собранного пакета не нашлось, то Conan автоматически скачает исходный код требуемой библиотеки и скомпилирует на Вашей рабочей машине. После этого Вы сможете спокойно использовать библиотеку, как будто она уже была кем-то собрана.

Как использовать

Имеем такой вот timer.cpp, который мы должны заставить компилировать и работать:

#include "Poco/Timer.h"
#include "Poco/Thread.h"
#include "Poco/Stopwatch.h"
#include <iostream>

using Poco::Timer;
using Poco::TimerCallback;
using Poco::Thread;
using Poco::Stopwatch;

class TimerExample{
public:
        TimerExample(){ _sw.start();}

        void onTimer(Timer& timer){
                std::cout << "Callback called after " << _sw.elapsed()/1000 << " milliseconds." << std::endl;
        }
private:
        Stopwatch _sw;
};

int main(int argc, char** argv){
        TimerExample example;
        Timer timer(250, 500);
        timer.start(TimerCallback<TimerExample>(example, &TimerExample::onTimer));

        Thread::sleep(5000);
        timer.stop();
        return 0;
}

Рассмотрим стандартный пример из документации. Хотим подключить в наш проект (предположим, что мы используем CMake) библиотеку POCO. Для этого в папке с проектом создаём файл conanfile.txt со следующим текстом:

[requires]

Poco/1.8.0.1@pocoproject/stable



[generators]

cmake

Разберём, что есть что в этом файле. В разделе Requires мы описываем нужные нам зависимости в виде НазваниеБиблиотеки/ВерсияБиблиотеки@ИмяМейнтейнера/СтабильностьПакета. Имя мейнтейнера — человек или организация, кто поддерживает пакет. Стабильность — просто показатель, насколько пакет стабилен. Обычно используют stable, testing, ci. Рекомендую использовать только stable пакеты.

В секции generators мы указываем, с чем мы хотим интегрироваться. В нашем случае указываем интеграцию с CMake. Conan для интеграции с CMake создаст автоматически файл conanbuildinfo.cmake, в котором будут определены переменные с путями к заголовочным файлам и уже скомпилированным библиотекам, которые мы будем использовать в нашем CMakeLists.txt:

project(FoundationTimer)
cmake_minimum_required(VERSION 2.8.12)
add_definitions("-std=c++11")

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

add_executable(timer timer.cpp)
target_link_libraries(timer ${CONAN_LIBS})

Обратите внимание на строки 5-6. В строке 5 мы подключаем ранее сгенерированный conanbuildinfo.cmake, а в 6-ой строке просто определяем макрос, который заставляет Conan магическим образом работать :-)

Теперь мы готовы к сборке. И перед стандартным запуском CMake мы должны попросить у Conan установить зависимости. Делается это следующей командой:
conan install /path/to/conanfile.txt
Обычно команда будет выглядеть просто как
conan install ..

Здесь происходит самое интересное — как Conan подтягивает зависимости

Порядок поиска зависимостей:

Проверяем локальный кеш.
Ищем в подключенных репозиториях нужный нам рецепт. Обращаю Ваше внимание, что поиск ведётся строго в том порядке, в каком у Вас подключены репозитории. Если пакет будет в двух репозиториях, то найдётся первый попавшийся.
Если рецепт был найден и есть уже собранная библиотека под Вашу конфигурацию, то просто качаем из репозитория пакет и сохраняем его в локальный кеш. Стоит отметить, что пакет выкачивается автоматически со всеми зависимостями к нему.
Если же под Вашу конфигурацию собранной библиотеки нет (или нет собранной какой-то зависимости библиотеки под Вашу конфигурацию), то Conan сообщит об этом и попросит запустить его ещё раз с флагом --build missing для запуска сборки пакета на Вашей машине.

Если Вы не хотите использовать кем-то собранную библиотеку и не доверяете чужим сборкам, то всегда можно указать флаг --build, чтобы библиотека и всё её зависимости были принудительно пересобраны на Вашей машине.

Поздравляю, все зависимости подтянуты с помощью Conan (если повезло)!

Conan и интеграция с билд-системой

Важно не просто скачать нужную версию библиотеки, но и подключить её правильно в проект. И желательно, чтобы это делалось как можно легче для разработчика. Поэтому Conan умеет интегрироваться с такими вещами как CMake, Visual Studio, Xcode и т.д. С полным списком Вы всегда можете ознакомиться здесь.

Conan как способ управления собственными зависимостями
Conan — это не только клиент для установки зависимостей из уже созданных кем-то репозиториев. Авторы данного менеджера зависимостей также любезно нам предоставили программу conan-server, которая позволяет буквально в пару-тройку действий поднять свой собственный сервер с готовыми библиотеками. Очень удобно для компаний, которые хотят наладить свою собственную инфраструктуру по управлению зависимостями.

Существующие проблемы

Ценность пакетного менеджера определяется удобством его использования и количеством пакетов. Если с первым особых проблем нет (Conan и правда очень удобен в использовании), то вот с количеством пакетов есть определённые проблемы. Если Вы посмотрите на основные репозитории, то увидите их целых два: conan-center и conan-transit. Согласитесь, это вводит в заблуждение — какой же использовать? Здесь нужно рассказать немного истории.

Изначально в Conan имелся один репозиторий, в который любой пользователь имел право грузить пакеты. Из-за этого репозиторий Conan очень быстро превратился в одну большую помойку. Авторы решили, что так дело продолжаться не может и решили создать репозиторий, в который пакеты будут попадать только после тщательной проверки. Так и появился conan-center. А старый, «мусорный» репозиторий решили не удалять, а просто его перевести в режим read-only и переименовали в conan-transit.

Где хранятся пакеты для Open-source библиотек

Хранением всех пакетов занимается организация JFrog Bintray. Не так давно Conan переехал на инфраструктуру Bintray, поэтому у нас появился доступ к более вместительному хранилищу пакетов, а также к CDN. Одним из самых интересных новшеств после переезда является то, что Вы можете создать абсолютно бесплатно свой собственный репозиторий для OSS пакетов. Если же Вы хотите приватности, то можете воспользоваться триал-версией на 30 дней, а потом придётся платить.

Bincrafters

Библиотек много, и ко всем хотелось бы иметь готовые пакеты. Команда Conan сейчас очень маленькая и занята в основном разработкой самого пакетного менеджера, поэтому им некогда пакетить всё подряд (хотя они постоянно ищут разработчиков в том числе и для пакетирования). Но пакетить библиотеки надо, иначе нет смысла в Conan. Так и появилась команда Bincrafters — команда энтузиастов, которая активно пакетит open-source библиотеки. У них сейчас открыта программа на Patreon по сбору средств для аренды дополнительных CI мощностей. Если Вы хотите присоединиться к команде — милости просим.

Что делать, если библиотеки X нет в Conan?

На данном этапе развития такое случается очень часто. Вы всегда можете оставить заявку на создание пакета здесь (перед этим убедитесь, что никто до Вас уже об этом не просил). Если заявка уже существует, то просто напишите в комментариях, что данная библиотека и Вам нужна. И, конечно, Вы сами можете опакетить библиотеку, все только спасибо скажут.

Наиболее полезные команды (на мой взгляд)

conan search <library_name_pattern> — поиск пакета в репозиториях по заданному шаблону
conan info — просмотр информации о пакете (лицензия, дата создания, адрес исходного кода пакета и т.д.)
conan remote — управление репозиториями Conan (добавление, удаление и т.д.)

Советы

Используйте только stable пакеты. Использование пакетов testing и ci не рекомендуется, так как могут ломаться регулярно.
Если надумаете писать свои рецепты, то пример хорошего рецепта можно посмотреть вот тут.
При создании пакетов крайне рекомендуется уже иметь настроенный CI под все целевые платформы. Проблема всплывают всегда там, где Вы их не ожидаете :-)
Не забывайте обновлять Conan. Может так случиться, что в Conan просто сломают обратную совместимость и рецепт, который работает с новым Conan, со старым уже работать не будет.
Рекомендуемый порядок поиска пакетов (на данный момент): conan-center, public-conan (репозиторий Bincrafters team), conan-transit, другие репозитории.

Полезные ссылки:

Сайт Conan
Bincrafters
Youtube материалы: раз, два, вебинар(1, 2, 3), три

Комментарии (64)

TargetSan
27.11.2017 22:14
#10540424
Увы, у Conan есть одна фундаментальная проблема — он работает исключительно с репозиториями пакетов. Т.е. нельзя использовать проект на Github или в любом другом хранилище кода как зависимость. Объявлять локальные папки как зависимости вроде можно, но как минимум заморочно. Разработчики аргументируют это тем, что Conan умеет разрешать конфликты версий и хранить бинарные артефакты.
1. Artem_zin
  28.11.2017 00:00
  #10540590
  И правильно делают, имхо. Посмотрите какие в Go проблемы из-за того что изначально выбрали такую схему
  1. TargetSan
    28.11.2017 12:37
    #10541232
    Репозитории Git не должны быть ни основным ни, тем более, единственным источником зависимостей. Но такая возможность должна быть, тем более в С++ мире, где разброд и шатания.
    
    Oxyd
    28.11.2017 17:57
    #10541868
    +1
    ИМХО не только GIT но и прочие SVN и даже, о ужас, CVS(до сих пор немало всякого хостится на сорсфорже, например). Возможно поддержку разных видов реп имеет смысл реализовать в виде плагинов.
  1. 0xd34df00d
    29.11.2017 01:59
    #10542494
    А какие там проблемы? Хаскелевский Stack умеет делать аналогично (ссылаться на конкретные коммиты в гите), и я как-то не заметил каких-то проблем.
    
    Artem_zin
    29.11.2017 02:27
    #10542528
    А разве я что-то говорил про хаскелевый Stack? :)
    
    Конкретно go get не умеет ни в коммиты, ни в теги, ни в ветки. То есть если у вас нет своего форка зависимости, вы постоянно ссылаетесь на HEAD дефолтной ветки репозитория.
    
    То есть, ни репродьюсибл билдов, ни нормального версионирования зависимостей и понимания вообще что попадает в бинарь (если самому это не трекать в какой-то мета файл).
    
    Ну и, в принципе, всё, помимо коммита, при стягивании зависимостей из гит репозиториев ненадежно, тк можно сделать force-push.
    
    Как люди живут с этим, делают CI и CD и потом спят спокойно мне вообще непонятно.
    
    Ну и, конечн, поражает, как Go комьюнити к этому относится, многие не понимают причин хотеть стабильный билд, некоторые еще и дизлайкают лол:
    
    https://github.com/golang/go/issues/21933
    
    https://habrahabr.ru/post/250281/#comment_8276057
    
    https://stackoverflow.com/questions/24855081/how-do-i-import-a-specific-version-of-a-package-using-go-get
    
    Благо другая часть комьюнити пришла с платформ где это норма и таки пытаются пропихнуть нормальный вендоринг, но, я так понимаю, в ванильный go get это всё равно не вольют.
    
    // P.S. сам не сварщик по Go, но много работаю с разными системами сборок/управления зависимостями.
    
    0xd34df00d
    29.11.2017 02:29
    #10542534
    +1
    Ужас какой. Тогда понятен ваш исходный комментарий.
    
    Artem_zin
    29.11.2017 02:49
    #10542564
    Да капец.
    
    Можно понять почему дефолтное поведение такое, что вот у Гугла монорепо и своему коду и процессу разработки они сильно доверяют.
    
    Но убеждать всю остальную часть индустрии, что это норма и только так всем и должно быть — это либо маразм, либо религиозность.
1. rkfg
  28.11.2017 00:38
  #10540644
  В этом плане хорошо сделали в Meson, он поддерживает как архивы исходников, так и коммит из git + дополнительно наложение патчей. К сожалению, патчи нужны практически всегда, т.к. зависимостью может быть только такой же Meson-проект. С другой стороны, скрипты для сборки намного проще и нагляднее, чем у CMake, так что портировать несложные библиотеки можно быстро.
  
  А у Conan, вроде, всё есть тоже, вот из примера в документации:
  
  def source(self): self.run("git clone https://github.com/memsharded/hello.git") self.run("cd hello && git checkout static_shared")
  1. ZaMaZaN4iK Автор
    28.11.2017 03:50
    #10540714
    Да, так можно выкачивать исходники откуда хотите.
  1. TargetSan
    28.11.2017 12:47
    #10541252
    Meson смотрел. Судя по доке, врапперы нельзя накладывать на репозитории исходников, только на архивы.
    Ну а предложенный вами способ можно реализовать практически в любой системе сборки, менеджер пакетов для этого не нужен. Интересовала поддержка git как полноценного источника:
    
    Выкачивание в общую папку кеша
    
    Учёт случаев, когда один и тот же репозиторий запрашивается транзитивно несколькими зависимостями
    
    Автоматическая сборка и предоставление её результатов зависимым пакетам — конкретно папки с публичными заголовочными файлами плюс артефакты сборки.
    
    При этом вполне можно было бы требовать, чтобы для такого источника было отдельное описание — какая версия какой ветке/коммиту соответствует. К сожалению, ни Conan, ни Meson не поддерживают такой кейз — по крайней мере в простом виде.
    
    rkfg
    28.11.2017 16:55
    #10541746
    Похоже на то, как делает Maven, который я очень люблю и уважаю за практически беспроблемную сборку с нуля, в том числе на пустых новых системах, где есть только JDK и собственно мавен. Сам скачает, сам скомпилит, главное, чтобы сеть работала и всё было в актуальном состоянии. Увы, для C++ такой подход не работает по фундаментальным причинам. В Java байткод запускается на любой платформе, чем язык и ценен, а у C++ имеется большой набор факторов несовместимостей: версия компилятора, его разновидность (Clang/G++/Borland/...), версия стандарта языка (98, 11, 14, 17), способ связи с внешними зависимостями (статическая линковка, динамическая, рантаймовая через dlopen/LoadLibrary/...) и, возможно, другие. Всё это порождает несовместимые ABI, число комбинаций которых быстро выходит из-под контроля. В Google давно поняли эти нюансы и сделали свой инструмент Bazel, который собирает абсолютно все библиотеки с нуля, так что получается предсказуемый и стабильный билд, но он как-то не очень популярен за пределами гугла, и с зависимостями у него тоже не всё гладко. В этом аспекте бинарный сетевой кэш Conan не выглядит сильно привлекательным — помимо и так немалого числа проблем при сборке проекта добавятся ещё и потенциальные нюансы собранных мейнтейнерами библиотек. Лучше уж всё качать в исходниках и собирать на локальной машине (я знаю, что Conan так может, но это не дефолтное поведение).
    
    Это к тому, что общий кэш и общие результаты компиляции, при всей их удобности, не всегда лучшее решение, особенно, в больших проектах. Инвалидация кэша — одна из сложнейших задач, как известно, так что не факт, что сэкономленное на сборке время пойдёт действительно в плюс, когда проект перестанет собираться из-за обновления компилятора. Транзитивные зависимости — тоже головная боль, ведь в этом случае одна библиотека может оказаться двух разных версий по двум путям зависимостей. Maven в этом случае предпочитает более новую автоматически, но если таких случаев много, за всеми не уследишь, и это может ВНЕЗАПНО породить проблемы на ровном месте (обновил библиотеку, а по её пятому колену зависимостей какая-то библиотека обновила свою зависимость, которая перекрыла такую же у другой, и всё превратилось в кашу).
    
    В Meson с этим строго: все зависимости, включая транзитивные, должны явно прописываться в корневом проекте, это гарантирует, что всё будет собрано однократно и иметь одну версию. Подход не без явных минусов, но гарантии такого рода на деле важнее неудобств при обновлении библиотек.
    
    Автосборка и выдача результатов как раз имеется в Meson, хотя и не стандартизована — subproject экспортирует две переменные, обычно inc и lib, которые достаточно добавить в проект верхнего уровня. Система добавит нужные флаги для инклудов и линковки с учётом всех путей до субпроекта, это реально удобно и работает! Вообще, меня Meson подкупил именно системой Wrap, которая сколь проста, столь и эффективна, хотя можно спорить, должна ли система сборки иметь управление зависимостями. Но сделали хорошо и надёжно, почему бы и нет.
    
    Судя по доке, врапперы нельзя накладывать на репозитории исходников, только на архивы.
    Да:
    
    Note that in this case you cannot specify an extra patch file to use. The git repo must contain all necessary Meson build definitions.
    Но нет большой проблемы организовать свой форк на том же гитхабе (или сервере организации), где сразу держать meson.build и обновлять его по мере необходимости при изменениях в апстриме, а во wrap-файл писать нужный коммит.
    
    TargetSan
    28.11.2017 17:29
    #10541816
    Это к тому, что общий кэш и общие результаты компиляции, при всей их удобности, не всегда лучшее решение, особенно, в больших проектах.
    Я имел ввиду локальный кеш, т.е. репозитории втягиваются в подпапки какой-то папки в домашнем каталоге пользователя. Если репозиторий уже есть — его никто не тянет повторно.
    
    В Meson с этим строго: все зависимости, включая транзитивные, должны явно прописываться в корневом проекте
    Вот этого и не хочется совершенно. Разве Meson не умеет писать lock-файл с конкретными версиями зависимостей? Этот подход как раз и придумали чтобы иметь мягкое задание версий зависимостей и при этом воспроизводимые билды.
    
    rkfg
    28.11.2017 18:17
    #10541920
    Я имел ввиду локальный кеш, т.е. репозитории втягиваются в подпапки какой-то папки в домашнем каталоге пользователя. Если репозиторий уже есть — его никто не тянет повторно.
    Можно завести issue, но что-то мне подсказывает, что в реалиях C++ это создаст больше проблем, чем решит, могу быть неправ. Часто используемые библиотеки и репозитории вообще имеет смысл захостить локально в организации или на своём сервере, а там уже время доступа не будет особой роли играть.
    
    Разве Meson не умеет писать lock-файл с конкретными версиями зависимостей? Этот подход как раз и придумали чтобы иметь мягкое задание версий зависимостей и при этом воспроизводимые билды.
    Можете раскрыть, что подразумевается под мягким заданием версий и lock-файлами?
    
    TargetSan
    29.11.2017 00:53
    #10542414
    Пусть у нас есть конфиг с зависимостями
    
    foo = "1.2" bar = "0.4"
    
    Версии указаны неточно, как можно видеть.
    При первичной сборке, менеджер сгенерирует файл, в котором записаны точные версии всех зависимостей и их транзитивных зависимостей. Всех пакетов, как-либо использованных при сборке.
    
    foo = "1.2.4" // foo's deps spam = "0.4.3" eggs = "3.14.16" // bar's deps eggs = "3.14.16"
    
    При повторной сборке, если менеджер видит такой лок-файл, он использует версии оттуда. Обновить их список можно отдельной командой. Таким образом, все версии будут зафиксированы до следующего принудительного апдейта — но автоматически, без ручной писанины.
    
    В cargo, где я это наблюдал, обычной практикой является держать такой файл под контролем версий для исполняемых проектов (или любых "конечных") и игнорировать для библиотек.
    
    rkfg
    29.11.2017 01:06
    #10542434
    Я думаю, в случае Meson этот подход не имеет смысла, т.к. у него, в отличие от Maven, нет единого репозитория зависимостей и индекса с версиями, поэтому найти «последнюю» версию на основе предложенной неточной не получится. Нужно указывать прямую ссылку на архив или коммит. В случае с git, возможно, прокатит резолв по тегам, но не факт, что будет работать стабильно — теги все оформляют по-разному.

gudvinr
27.11.2017 22:28
#10540454
+1
Пакетные менеджеры для C++, которые сейчас есть, чудовищно сложны, либо неудобно встраиваются в процесс сборки, на мой взгляд. Либо в базе одного есть один пакет, но нет другого, а у другого — есть второй, но нет первого, а третий — устаревший.
Отсутствие какого-то де-факто стандарта убивает всю систему зависимостей, в таком случае проще иметь систему которая делает "бери отсюда, делай то, клади туда".

У cmake есть ExternalProject, но над ним приходится городить самопальные костыли, чтобы это было расширяемо.
Hunter добавляет функциональности, но подготовка пакетов для использования требует времени, становится неудобно.
cget почти не требует конфигурации самих зависисостей, но тоже со своими косяками.
Есть хоть один менеджер зависимостей, который просто работает с пакетами, которым достаточно cmake или ./configure && make && make install?
1. ZaMaZaN4iK Автор
  27.11.2017 22:32
  #10540458
  Проблема в том, что вот это «просто» далеко не так просто с таким то зоопарком. Вы всегда можете посмотреть, как выглядит пример простого рецепта на Conan, где создаётся пакет для библиотеки на основе CMake: тыц
1. NukeBird
  01.12.2017 02:31
  #10546722
  В том же hunter проще всего добавлять библиотеки с cmake-конфигами. Если же перед нами чистые сырцы или какой-нибудь autotool — приходится все переделывать руками, делая форк (см. hunter-packages)
  
  Хотели вот добавить SFML, но нужно добавить libflac, libogg и libvorbis в качестве отдельных пакетов + перепахать SFML'ный CMakeLists. Все дело в том, что все зависимости лежат в собранном виде — а это уже: 1)возможные проблемы с совместимостью компиляторов (рано или поздно зависимости устареют и перестанут жеваться более свежими компиляторами) 2)менеджер зависимостей должен сам разруливать зависимости. Честно говоря, геморрой ещё тот
  
  Если же говорить о проблеме в целом, то корень один — нестандартизованность. Все проекты по-разному устроены и юзают разные плюшечки + параллельно пытаются выбиться вперед совершенно разные менеджеры пакетов — отсюда и проблемы. Как решить проблему — понятия не имею, она нетривиальна… :(

eao197
27.11.2017 23:04
#10540516
А есть какая-нибудь хорошая инструкция о том, как делать пакеты для conan-а? Именно хорошая инструкция, чтобы можно было проштудировать и таки сделать пакет.

PS. С conan-ом дела не имел, поэтому не знаю, насколько хороша их собственная документация.
1. ZaMaZaN4iK Автор
  27.11.2017 23:29
  #10540562
  +1
  Да, конечно есть. Вот тут очень хорошая документация, на мой взгляд.

iCpu
28.11.2017 10:49
#10541036
Банальный перевод документации — и очень небрежный. С такой рекламой и антирекламы не надо.
Что я ожидал увидеть второй строчкой статьи? Команду поиска пакета в удалённой репе.
```
conan search <package> -r conan-center
```
ZaMaZaN4iK, спасибо за наводку, конечно, инструмент хороший и всё такое, но не надо так. Сделай сначала «коротко, зачем это вам» со сценарием использования от установки до успешной сборки, а потом уже наматывай воду на вилы, как всё плохо с пакетными менеджерами на плюсах.
1. ZaMaZaN4iK Автор
  28.11.2017 11:45
  #10541116
  +1
  Не все могут в английский. И высказывания вида «Не знаешь английский — не программист» лично я не воспринимаю серьёзно.
  
  Целью и не являлся перевод, хотя явно с него взято очень много материала. И какие именно небрежности Вас печалят?
  
  Я, конечно, учту замечания, но не вижу большой проблемы в таком стиле изложения.
  
  Про антиреклмау не понял, если честно.
  1. iCpu
    28.11.2017 13:05
    #10541272
    Меня печалит, что я не увидел полного сценария: «я нуб» — «я скачал» — «я нашёл пакеты в репе» — «я настроил» — «я ногебаю». Ни в той документации, ни в вашей статье. Всё обрывками, с предзнанием, без связного повествования и пояснений, да ещё половина команд ничего не выводит.
    Например, строка из доков conan search Poco/1.7.8p3@pocoproject/stable не отобразит ничего.
    Меня печалит, например, что ни слова не сказано про репы, где всё лежит. Точнее, мне любезно сообщили «А ещё есть conan remote». Спасибо, хорошая наводка, но что в пункте «я нуб» не понятно?
    Меня печалит, что, например, что поиск по репозиториям чувствителен к раскладке, но об этом нигде не написано.
    Меня печалит, что когда я сказал,
    
    >conan search openssl -r conan-center
    
    мне ответили
    
    There are no packages matching the openssl pattern
    
    Это, знаете ли, удар ниже пояса. Что ещё смешнее, я нашёл флаг --case-sensitive, гарантирующий чувствительный к раскладке поиск. Спасибо, хорошо, как мне от него избавиться? Никак? Ох, хорошо, спасибо.
    
    И, к слову, я ни капельки не сказал про «перевод не нужен». Естественно, нужен. Актуальный для последнего релиза программы. И, желательно, достаточный для работы. Ну, то есть, стоило дойти хотя бы до docs.conan.io/en/latest/getting_started.html#inspecting-dependencies
    И после этого я не должен называть ваш перевод небрежным? Ещё раз, спасибо, что хоть такой, без вас бы я не узнал об этом инструменте.

NelSon29
28.11.2017 11:39
#10541106
В моих проектах используется vcpkg и, если не считать детских болезней с прокси, на работе мы полностью довольны.
1. ZaMaZaN4iK Автор
  28.11.2017 11:40
  #10541108
  а как решаете проблему на не-Windows платформах? Или у Вас целевая платформа только Windows?
  1. NelSon29
    28.11.2017 11:58
    #10541140
    Целевая платформа у нас вообще без ОС (система на кристалле с ядром ARM и двумя DSP), а модели мы пишем на Windows в VS2015/VS2017
    
    ZaMaZaN4iK Автор
    28.11.2017 12:05
    #10541150
    Да, тогда у Вас есть возможность использовать vcpkg. К сожалению (или к счастью), я постоянно сталкиваюсь с такими кроссплатформенными проектами, где vcpkg бессилен.

tgz
28.11.2017 11:41
#10541112
Пока не напишут стандарт так и будет боль и страдания. Именно поэтому им никогда не догнать rust cargo.
1. ZaMaZaN4iK Автор
  28.11.2017 11:47
  #10541120
  Ходят разговоры о том в Комитете о том, что было бы неплохо это дело стандартизировать. Но это пока только разговоры :-)
1. Gorthauer87
  28.11.2017 11:51
  #10541122
  Есть еще прикольная инициатива: cargo native называется.
  https://internals.rust-lang.org/t/pre-rfc-cargo-build-and-native-dependency-integration-via-crate-based-build-scripts/5708
  Если взлетит, то можно будет cargo просто юзать для c++ и не парится особо.
  1. ZaMaZaN4iK Автор
    28.11.2017 12:06
    #10541154
    Спасибо, не знал про такую инициативу.
1. eao197
  28.11.2017 12:06
  #10541152
  +1
  По большому счету, проблема не столько в менеджере зависимостей, сколько в том, что в C++ нет де-юре (да и де-факто так же) стандартной системы сборки. Поэтому взять и подтянуть в свой проект исходники нужных зависимостей — это даже не полдела. Это вообще элементарно.
  
  А вот собрать все это с учетом зоопарка компиляторов и платформ — вот это самое печальное. В Rust-е такой проблемы нет, т.к. сам Rust пока:
  
  во-первых, представлен всего одним компилятором, поэтому нет надобности заботиться о скриптах сборки для совершенно разных компиляторов/линкеров с совершенно разными наборами ключей;
  
  во-вторых, не страдает от того, что кто-то вынужден сидеть на компиляторах 3-, 5- или даже 10-ти летней давности. Из-за чего при сборке нужно проверить, какой компилятор в наличии и что он поддерживает. Да и не только компилятор, но и ОС (отчего autotools все еще в ходу на Unix-ах);
  
  в-третьих, Rust пока еще не представлен на таком же спектре платформ, как C и C++. Некоторые из которых весьма специфические и без какого-то аналога autotools там не обойтись.
  
  Так что догонять Cargo в C++ — это в принципе бесполезное занятие. Нужно что-то, чтобы учитывало реалии C++.
  1. tgz
    28.11.2017 13:59
    #10541382
    1. поддержать разные компиляторы — это проблема? Ну так себе аргумент
    2. убрать легаси из поддержи — это проблема? Кто на легаси сидит и так не имеет ничего, так почему из-за них остальные 99% должны страдать?
    3. никто ж не запрещает использовать autotools (пусть и не как часть стандарта, а что-то навроде расширения)
    
    eao197
    28.11.2017 14:03
    #10541400
    1. поддержать разные компиляторы — это проблема? Ну так себе аргумент
    Сами-то пробовали? Где можно результаты ваших трудов увидеть?
    
    2. убрать легаси из поддержи — это проблема?
    Очевидно, что вы даже не представляете себе насколько.
    
    Кто на легаси сидит и так не имеет ничего, так почему из-за них остальные 99% должны страдать?
    Откуда 99%? Из вашего уютного менямирка? Как вы думаете, какую часть рынка C++ разработчиков сейчас составляет поддержка и развитие легаси кода?
    
    tgz
    28.11.2017 15:15
    #10541532
    -1
    1. Некоторые вещи очевидны и без «пробовали».
    2. Проблема напечатать в стандарте «это деприкейтед»? Охотно верю.
    3. «Развитие легаси». Делом лучшей займитесь, тогда может и у вас появится система сборки, собирающая любой проект одной командой.
    Впрочем прожект-лиду что-то объяснять бесполезно.
    
    eao197
    28.11.2017 15:25
    #10541560
    1. Некоторые вещи очевидны и без «пробовали».
    В переводе на русский это означает «не разбираюсь, но мнение имею».
    
    2. Проблема напечатать в стандарте «это деприкейтед»? Охотно верю.
    Что вы собрались помечать как «деприкейтед»? Вот в C++11 так пометили std::auto_ptr, а из C++17 вообще уже выбросили. Что никак не отразилось на проектах, которые все еще живут на C++98/03, приносят деньги и в обновление которых владельцы кода не особо хотят вкладываться.
    
    Но интересно, что вы собрались помечать в стандарте как «деприкейтед» касательно систем сборки и управления зависимостями?
    
    3. «Развитие легаси». Делом лучшей займитесь, тогда может и у вас появится система сборки, собирающая любой проект одной командой.
    Удивлю вас, но у нас есть и своя система сборки, и своя система управления зависимостями. Свои проекты в итоге собираются одной командой. Главный вопрос при этом: «Что делать с не своими?». Так что я говорю о том, в чем хоть чуть-чуть разбираюсь, в отличии от.
    
    Впрочем прожект-лиду что-то объяснять бесполезно.
    Можно ли развернуть подробнее? Если бы в профиле стоял какой-то другой шилдик, вроде «system architect» или «co-founder» — это что-то бы изменило?
    
    Artem_zin
    29.11.2017 10:52
    #10542958
    При таком зоопарке тулинга может плюсам нужна container-based система сборки? Чтобы было воспроизводимое окружение и вот это все, но это правда только для таргетинга Linux.
    
    0xd34df00d
    29.11.2017 19:44
    #10544220
    Да и распространения тогда уж тоже.
    
    Artem_zin
    30.11.2017 01:10
    #10544670
    Если имеется в виду паблишинг зависимостей — то да, это подразумевается, иначе в чем смысл)
    
    ZaMaZaN4iK Автор
    28.11.2017 14:48
    #10541472
    
    Это не так просто, как Вы думаете.
    
    А что Вы подразумеваете под легаси? Хочу напомнить, что не так просто брать и что-то депрекейтить. Потому что это что-то может активно кем-то использоваться. В этом весь C++
  1. VioletGiraffe
    28.11.2017 19:19
    #10542002
    +1
    Вы всё правильно сказали, но ещё одна часть проблемы, как мне кажется — библиотеки на С / С++ с чересчур замороченной сборкой и миллионом дефайнов, которые нужно правильно определить.
    
    eao197
    28.11.2017 19:24
    #10542004
    Да, это еще одна сторона данной проблемы. Где-то это пересекается с проблемой autotools (т.е. определение макросов типа HAVE_something для учета особенностей конкретной платформы). Где-то посредством макросов регулируются фичи самой библиотеки (элементарный пример: сборка в виде статической или динамической библиотеки). В любом случае с этим приходится считаться.

ZaMaZaN4iK Автор
28.11.2017 11:46
#10541118
del

NukeBird
28.11.2017 17:51
#10541858
Есть ещё hunter — менеджер пакетов, который встраивается в CMakeLists. Причем если hunter не установлен, то CMake сам установит его

Разработчики там довольно отзывчивые, новые пакеты добавляются не так уж сложно (особенно если проект основан на CMakeLists с использованием конфигов)
1. NukeBird
  28.11.2017 19:26
  #10542008
  А почему заминусовали-то? Это ещё один пакетный менеджер, как минимум полезно ознакомиться. Я не преверженец какого-то одного пакетного менеджера — в сфере С++ с этим до сих пор не все хорошо, нет монополиста (хотя есть позитивные тенденции, и я надеюсь что какой-то один менеджер рано или поздно станет общепринятым, стандартным)
  1. ZaMaZaN4iK Автор
    28.11.2017 19:48
    #10542024
    Возможно потому, что он упоминается в статье тоже :-)
    
    NukeBird
    28.11.2017 22:19
    #10542202
    черт, не заметил! Виноват :)

firk
28.11.2017 18:58
#10541978
-2
Ранее уже были попытки создания такого средства для C++. Может, некоторые из Вас помнят такую вещь как biicode. Он, к сожалению, приказал долго жить.
Первый раз слышу, но я не удивлён, что проект загнулся. Этот скорее всего сделает то же самое. "Менеджер пакетов к с++" — идея изначально сомнительная. Для кодинга в стиле "песочница с набором игрушек" уже есть всякие php/js/итд.
Ну и в конце концов во всех современных популярных ос кроме винды уже есть встроенные менеджеры пакетов, не привязанные в компиляторам.
1. iroln
  28.11.2017 19:29
  #10542014
  "Менеджер пакетов к с++" — идея изначально сомнительная. Для кодинга в стиле "песочница с набором игрушек" уже есть всякие php/js/итд.
  Два вопроса: почему изначально сомнительная идея и какой стиль кодинга на C++? В крупных проектах может быть > 50 библиотек зависимостей. Как поддерживать такой зоопарк? Мы сейчас используем CMake ExternalProject и тонны костылей, например. А вы?
  1. firk
    28.11.2017 19:52
    #10542034
    -1
    Серьёзные крупные проекты обычно сильно индивидуальны, и обойтись "нашёл в инете менеджер — сказал — настроил — запустил — подошло" там скорее всего не получится (а если и получится, то выглядеть оно будет как раз костылём). А такие пакетные менеджеры претендуют именно на такую роль — законченный абстрактный продукт, который подходит всем.
    "Стиль кодинга" — я возможно плохо выразился. Имелось ввиду то, что во всяких пхп-подобных языках принято тянуть в проект всё подряд, не особо разбираясь в том как оно работает. В серьёзных языках так обычно делать не принято (а те, у кого было принято раньше, плавно переходят на новые языки, более для этого подходящие), а значит затраты времени на знакомство с новой используемой библиотекой будут всё равно заметно больше, чем затраты времени на чисто техническое подключение её к проекту. А значит тут техническое подключение (а это и есть роль пакетных менеджеров) — не совсем то место, вокруг которого надо спешить строить автоматизирующий инструментарий. Я не утверждаю, что везде так, но в среднем сложившаяся ситуация, по-моему, такая.
    
    salas
    28.11.2017 21:09
    #10542124
    Не могу удержаться от любопытства. Что такое серьёзный язык и, в частности, является ли таковым Java?
    
    VioletGiraffe
    28.11.2017 21:25
    #10542148
    В Java нет проблем с зависимостями, к чему этот пример был?
    
    salas
    28.11.2017 21:43
    #10542164
    Именно! Никакого, AFAIK, дефицита инструментов для
    
    кодинга в стиле "песочница с набором игрушек"

0xd34df00d
29.11.2017 02:05
#10542500
Окей, перешёл я, скажем, на Conan, наваял с его использованием какую-то опенсорс-тулзу с десятком зависимостей. Как её теперь правильно пакетировать под Debian, openSUSE и Gentoo? Можно ли сказать Conan'у, чтобы он не качал никакие зависимости, а использовал дистрибутивные? Не идёт ли это вразрез с его идеологией?
1. ZaMaZaN4iK Автор
  29.11.2017 16:08
  #10543684
  Нет, вы не можете указать Conan, чтобы для билда он использовал дистрибутивные. Conan не занимается сборкой под каждую ОС — это не его заботы. Вы можете спокойно в Вашем CMake файле написать, чтобы в определённом режиме собиралась либа с системными либами, а не с конановскими.
  
  И не совсем понимаю пункта про идеологию.
  1. 0xd34df00d
    29.11.2017 19:47
    #10544230
    То есть, получается, CMakeLists.txt надо писать всё равно по факту в старом стиле, просто теперь ещё добавляется дублирующееся указание зависимостей в conanfile.txt. И тогда возникает, на мой взгляд, резонный вопрос: а зачем в такой ситуации вообще Conan?
    
    ZaMaZaN4iK Автор
    29.11.2017 21:47
    #10544422
    Ну если вы собираете приложение на конкретном дистре, то никуда не уйти от этого.
    
    Зачем нужен Conan: там, где пакетного менеджера нет и есть кроссплатформенный проект. Вы имеете свои версии зависимостей и хотите сами ими управлять, а не надеяться на мейнтейнеров (не относите сюда всякие флатпаки, снапы и так далее).
    
    Надеюсь, что понятно обьяснил :-)
    
    firk
    29.11.2017 23:41
    #10544566
    там, где пакетного менеджера нет
    То есть главным образом на винде. О чём я уже писал но меня почему-то заминусовали.
    
    ZaMaZaN4iK Автор
    29.11.2017 23:59
    #10544594
    Не совсем. Не во всех дистрибутивах есть возможность держать все версии библиотек (в той же Федоре только самые последние версии пакетов). И может так получиться, что Вам нужна немного более старая версия пакета, а новая Вас не устраивает (да, апгрейд на новые версии библиотек тоже риск, и на это не так просто решиться). Пакетному менеджеру дистра всё равно на ваше желание. Конану — нет. Он не обновит автоматически зависимость. Что у Вас будет прописано в файле зависимостей, то и подтянется.
    
    0xd34df00d
    30.11.2017 00:46
    #10544642
    Федора — не роллинг-дистрибутив. Зачем вам обновляться на новую версию, если у вас со старой всё работает, и рисковать обновляться вы не готовы?
    
    Как мне потом эту софтину распространять? Со всеми библиотеками в архиве, что ли?
    
    ZaMaZaN4iK Автор
    30.11.2017 05:00
    #10544776
    Обновляться затем, чтобы мейнтейнеры обновили версии программ, в которых я работаю. Но при этом я не хочу обновлять зависимости либ, с которыми я работаю. Риск обновления системных программ и риск обновления зависимостей к моей проге — совсем разные вещи.
    
    Всё очень просто. Если Вы готовы доверить мейнтейнить зависимости мейнтейнерам — то путь сами разбираются, с какими зависимостями прога работает. Если хотите управлять сами — flatpak, snap, AppImage.

r3verser
29.11.2017 11:56
#10543080
Как в нем искать пакеты для Си? Не нашел фильтров.
1. ZaMaZaN4iK Автор
  29.11.2017 16:06
  #10543678
  Такого фильтра нет.

Conan: менеджер зависимостей для C/C++ +36

Зачем нужен менеджер зависимостей

Предыдущие попытки

Как установить?

Особенности

Как использовать

Conan и интеграция с билд-системой

Существующие проблемы

Где хранятся пакеты для Open-source библиотек

Bincrafters

Что делать, если библиотеки X нет в Conan?

Советы

Полезные ссылки:

Комментарии (64)

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор

ZaMaZaN4iK Автор