История изменений

Нет, конкретно с Conan дело совсем не в этом, а в крайне дурной политике компании-разработчика (BinTray), для которой Conan - это всего лишь реклама их платной хранилки (Artifactory), и они вендорлочат рецепты в дефолтной репе как могут.

Например, у них есть вредная политика, согласно которой сгенерированные config-файлы для CMake (это чтобы в клиентской сборочной системе работал find_package()) должны быть удалены, и вместо них использован файл с таргетами, синтезированный Conan по описаниям в рецепте. То же самое касается pkg-config. С точки зрения автора библиотеки это совершеннейшее свинство, потому что пользователь, делая find_package() получит не то что задумал и задокументировал автор, а фигню которую синтезировал Conan. Если автор написал и экспортировал дополнительные функции в CMake для своей библиотеки (многие библиотеки так делают), это тоже всё будет вырезано.

Другой пример отвратительной политики - активное продвигание в документации и примерах интрузивного генератора с путями к зависимостям, который заставляет патчить сборочную систему проектов специально под Conan. В то время как тот же CMake прекрасно умеет неинтрузивный инжект сгенерированных путей через -DCMAKE_PROJECT_INCLUDE. Да и в целом документация активно настаивает на устаревших или откровенно вредных практиках, о чём у них даже заведён баг, но это в данном случае не относится к делу.

Спешу подчеркнуть, что ничего из этого не вызвано техническими ограничениями Conan как инструмента. Это исключительно политики на пакеты в дефолтной репе. Понятно, что это репа работает на мощностях вендора, и чтобы разместить там что-то своё, надо подчиняться их правилам. Но как следствие, глядя на просто изуродованные под эти политики рецепты, рекомендовать Conan для широкого круга разработчиков я не стану.

Нет, конкретно с Conan дело совсем не в этом, а в крайне дурной политике компании-разработчика (BinTray), для которой Conan - это всего лишь реклама их платной хранилки (Artifactory), и они вендорлочат рецепты в дефолтной репе как могут.

Например, у них есть вредная политика, согласно которой сгенерированные config-файлы для CMake (это чтобы в клиентской сборочной системе работал find_package()) должны быть удалены, и вместо них использован файл с таргетами, синтезированный Conan по описаниям в рецепте. С точки зрения автора библиотеки это совершеннейшее свинство, потому что пользователь, делая find_package() получит не то что задумал и задокументировал автор, а фигню которую синтезировал Conan. Если автор написал и экспортировал дополнительные функции в CMake для своей библиотеки (многие библиотеки так делают), это тоже всё будет вырезано.

Другой пример отвратительной политики - активное продвигание в документации и примерах интрузивного генератора с путями к зависимостям, который заставляет патчить сборочную систему проектов специально под Conan. В то время как тот же CMake прекрасно умеет неинтрузивный инжект сгенерированных путей через -DCMAKE_PROJECT_INCLUDE. Да и в целом документация активно настаивает на устаревших или откровенно вредных практиках, о чём у них даже заведён баг, но это в данном случае не относится к делу.

Спешу подчеркнуть, что ничего из этого не вызвано техническими ограничениями Conan как инструмента. Это исключительно политики на пакеты в дефолтной репе. Понятно, что это репа работает на мощностях вендора, и чтобы разместить там что-то своё, надо подчиняться их правилам. Но как следствие, глядя на просто изуродованные под эти политики рецепты, рекомендовать Conan для широкого круга разработчиков я не стану.