Как мне управлять зависимостями в проектах с открытым исходным кодом на C или С++?

У меня есть несколько приложений с открытым исходным кодом. Они зависят от нескольких сторонних компонентов, в частности Crypto ++ и Boost. Есть несколько вариантов:

  • Поместите сторонний код в элемент управления версиями и включите его в дистрибутивы моего кода. С одной стороны, это самый простой способ использовать людей, поскольку они могут компилироваться непосредственно из моего исходного хранилища. С другой стороны, они могут потерять источник загрузки полосы пропускания, который у них уже есть, или в конечном итоге придется бороться с моей библиотекой, чтобы удалить сторонние биты. Кроме того, у инструментов управления источниками часто возникают проблемы с массивными библиотеками, такими как Boost.
  • Не включать сторонний код вообще. Это заставляет людей уходить с дороги, чтобы иметь возможность использовать мою библиотеку. С другой стороны, это означает, что мой исходный репозиторий и дистрибутивы будут небольшими.
  • Что-то, чего я еще не ожидал.

Что мне делать?

Примечание. Я не работаю в среде, где допустимы зависимость от сопоставления зависимостей, например aptitude, apt-get или yum.

ОТВЕТЫ

Ответ 1

Вариант 3: не включайте его в свой дистрибутив кода, а вместо этого добавляйте (ссылку на) загрузку, которая должна соответствовать самой последней версии, которую вы поддерживаете.
Кроме того, явно укажите свои зависимости и самые последние версии, которые вы поддерживаете.

Это позволяет пользователям делать все, что захочет. Хотите, чтобы ваш код зависел? Загрузите оба источника из одного источника. Хотите только часть зависимостей, потому что у вас есть другие? Загрузите часть из них. Хотите только свой код? Загрузите его отдельно.

Вариант 4: предлагать 2 версии, в том числе зависимости и другие, но не в сочетании с опцией 3 выше.

Ответ 2

Я предлагаю Autoconf, который был разработан, чтобы отвлечь эти заботы от вас.

Я сомневаюсь, что вы можете поддерживать скрипты сборки для всех ваших зависимостей во всех платформах. Другая проблема с сохранением стороннего кода в вашем svn заключается в том, что теперь вам также нужно отслеживать их зависимости и так далее.

Ответ 3

Я думаю, что это хорошая идея иметь зависимости в SVN. Таким образом, разработчики могут просто проверить и скомпилировать. Также вы избегаете проблем с различными несовместимыми версиями ваших зависимостей.

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

Ответ 4

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

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