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

Ответ 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 из официальных драйверов или любая другая библиотека, которая предлагает несколько выпусков, и каждый может решить все символы, но, вероятно, есть версия, более зрелая, чем другие, и вы может попросить компилятор выбрать правильный, потому что они все одинаковы для своих целей.