Какова теоретическая причина того, что производство зависимостей С++ не автоматизировано?

С++ Buildsystem с возможностью компиляции зависимостей заранее

В Java есть Maven, с которым приятно работать, просто определяя зависимости, которые уже скомпилированы и помещены в стандартный каталог Mavens, что означает, что расположение зависимостей стандартизировано, а не часто используемый способ иметь несколько местоположений (дайте мне перерыв, как и все, кто помнит установленные по умолчанию каталоги для определенных депо) зависимостей C/С++.

Это неэффективно для каждого отдельного разработчика, чтобы он чаще всего находил, читал, знакомился с параметрами конфигурации/сборкой и, наконец, собирал для каждой зависимости просто сборку проекта.

Какова теоретическая причина, по которой это не реализовано?

Почему было бы сложно предоставить пакеты из следующих вариантов с форматом декларации, подобным maven?

version
platform (windows, linux)
src/dev/bin
shared/static
equivalent set of Boost ABI options when applicable

Чтобы вручную перейти на веб-сайты и искать зависимости в 2013 году для самого старого основного языка программирования, абсурдно.

Ответ 1

Теоретических причин нет. Существует много практических причин. Существует слишком много разных способов обработки вещей в мире С++, чтобы легко стандартизировать систему зависимостей:

Различия в реализации - С++ - сложный язык, и разные реализации исторически различаются по тому, насколько хорошо они его поддерживают (насколько хорошо они могут корректно обрабатывать различные умеренные или продвинутые С++-коды). Таким образом, нет никакой гарантии, что библиотека может быть построена в конкретной реализации.
Различия в платформе. Некоторые платформы могут не поддерживать исключения. Существуют различные реализации стандартной библиотеки с различными плюсами и минусами. В отличие от стандартизованной библиотеки Java, API Windows и POSIX могут быть совершенно разными. Файловая система даже не является частью стандартного С++.
Различия в компиляции - статические или общие? Отладка или производство? Включить дополнительные зависимости или нет? В отличие от Java, который имеет очень стабильный байт-код, отсутствие С++ стандартного ABI означает, что код может неправильно ссылаться, даже если он построен для одной и той же платформы одним и тем же компилятором.
Построение системных различий - Make файлы? (Если это так, GNU Make или что-то еще?) Autotools? CMake? Файлы проекта Visual Studio? Что-то еще?
Исторические проблемы. Из-за возраста C и С++ популярные библиотеки, такие как zlib predate, строят системы, такие как Maven, совсем немного. Почему zlib переключается на какую-то гипотетическую систему сборки С++, когда работает? Как новая библиотека более высокого уровня может перейти к некоторой гипотетической системе сборки, если она зависит от библиотек, таких как zlib?

Два дополнительных фактора усложняют:

В Linux системы дистрибутивного дистрибутива do предоставляют стандартизованные репозитории двоичных файлов заголовков библиотеки разработки (обычно) стандартизованные ABI и простой способ задания зависимостей построения проекта. Существование этих (специфичных для платформы) решений снижает стимул для кросс-платформенного решения.
При всех этих усложняющих факторах и ранее существовавших подходах любая попытка создать стандартную систему сборки столкнется с проблемой, описанной в XKCD "Стандартах" .:
Ситуация: существует 14 конкурирующих стандартов.
"Нужно разработать один универсальный стандарт, который охватывает все случаи применения".
Вскоре: существует 15 конкурирующих стандартов.

Со всем сказанным:

Есть надежда на будущее. Например, CMake, похоже, постепенно заменяет другие системы сборки. Некоторые из разработчиков Boost запустили Ryppl, чтобы сделать то, что вы описываете.

Ответ 2

(также опубликовано в связанном вопросе)

Сейчас я работаю над инструментом, способным автоматически устанавливать все зависимости приложения C/С++ с точной версией:

компилятор
LIBS
инструменты (cmake, autotools)

Сейчас это работает, для моего приложения. (Установка UnitTest ++, Boost, Wt, sqlite, cmake все в правильном порядке)

Инструмент под названием "Менеджер версий С++" (вдохновленный отличным менеджером версий Ruby) закодирован в bash и размещен на github: https://github.com/Offirmo/cvm

Любые советы и предложения приветствуются.

Ответ 3

Хорошо, сначала система, которая разрешает все зависимости, не делает вас продуктивной по умолчанию, потенциально это может сделать вас еще менее продуктивным.

Что касается различий между языками, я бы сказал, что на Java у вас есть пакеты, которые удобны, когда вам нужно организовать и дать ограниченный горизонт вашему коду, в С++ у вас нет эквивалентной концепции. В С++ все библиотеки, которые могут решить символ, достаточно хороши для компилятора, единственное реальное требование для библиотеки - иметь определенный ABI и разрешать необходимые символы, нет автоматических способов, которыми вы можете работать, чтобы выбрать правильный библиотека, а также решение символа, это просто вопрос связывания вашей функции с реальной реализацией, это даже не гарантирует, что правильный этап связывания сделает ваше приложение работать.

К этому вы можете добавить важные переменные, такие как версия библиотеки, различные реализации одной и той же библиотеки и разные библиотеки с тем же именем методов.

Примером является библиотека Mesa VS opengl lib из официальных драйверов или любая другая библиотека, которая предлагает несколько выпусков, и каждый может решить все символы, но, вероятно, есть версия, более зрелая, чем другие, и вы может попросить компилятор выбрать правильный, потому что они все одинаковы для своих целей.