Есть ли какие-либо усилия по созданию менеджера пакетов для С++?

Ответ 1

Если вы используете MinGW, уже есть менеджер пакетов, похожий на apt-get/aptitude, который делает то, что вы хотите: mingw-get

Он ведет себя аналогично Debian apt-get/aptitude. Среди пакетов, которые уже включены, вы можете найти expat, libxml2, zlib, pthread и т.д.

Очевидно, вам понадобится копия MinGW, чтобы начать работать с ней.

Ответ 2

Рассматривали ли вы Git как диспетчер пакетов? Я использовал подмодули Git для зависимостей и подзависимостей и в сочетании со бесплатными сервисами хостинга Git, идея довольно сильная.

Просто зайдите в проект Git,

git submodule add git://somehosting.com/you/package.git
git submodule init package
git submodule update package
cd package && ./configure --stuff && make && cd ..

Чтобы выбрать конкретные версии зависимостей,

cd package && git checkout v3.2 && cd .. && git add package/
git commit -am "package version 3.2 pinned" && git push

Теперь вы привязали свою зависимость пакета к определенному тегу и сохранили ваши настройки в репозитории проектов. В следующий раз, когда кто-то сделает:

git pull && git submodule update

Их зависимость от пакета также будет привязана к v3.2.

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

Итак, у нас есть загрузка пакетов, версии зависимостей, и мы можем эмулировать "подписание пакетов". Одной недостающей частью являются предварительно построенные двоичные файлы, которые, на мой взгляд, не являются абсолютной необходимостью. Еще одна недостающая часть - глобальное управление пакетами. Вам придется вручную управлять каждым репозиторием Git при обновлении зависимости зависимостей.

Ответ 3

Начиная с NuGet 2.5, NuGet поддерживает собственные проекты. Однако сделать пакет вручную довольно сложно, поэтому они предлагают использовать CoApp Powershell Tools для NuGet (здесь). Используя эти инструменты, теперь вы можете размещать свои пакеты C/С++ на NuGet.

Ответ 4

Ответ заключается в использовании Conda для управления упаковкой/зависимостью и любого инструмента, который вам нравится для создания (я использую CMake).

Посмотрите здесь:

http://conda.pydata.org/

Конда похожа на менеджеров пакетов, таких как apt-get, yum, nuget и т.д., но с несколькими важными преимуществами:

1) полностью кросс-платформенный (в настоящее время Linux, Windows и OSX, но другие платформы могут быть легко добавлены)

2) НЕ требует доступа root. На самом деле, ваши системные пакеты вообще не заботятся. Это похоже на создание целого стека (вплоть до libc, если хотите) в вашем homedir, за исключением того, что кто-то уже построил их для вас. Эта магия достигается за счет того, что пакеты перемещаются.

3) вы можете поддерживать столько разных сред, сколько хотите бок о бок. Требуется ли одному из ваших приложений python 2.7.6, но другому нужен python 2.7.4? Нет проблем - они могут сосуществовать в мире

4) вы больше никогда не будете вынуждены поддерживать отдельные сборки для различных дистрибутивов Linux. Правильно построенная среда Conda будет работать над любым из них. Не забывайте и о других платформах (например, Windows и OSX)!

5) вы больше не состоите в браке с версиями библиотек, которые были решены вами системой или ИТ-отделом. Например, я был вынужден работать с узлами RHEL5. На Питоне есть шутка (более 10 лет). Используя Conda, я обошел эту боль и смог работать с любой версией Python, которую я хотел, не затрагивая никого.

6) среды можно закрепить в "установщиках" для распространения.

7) вы можете сохранить свой собственный репозиторий за вашим брандмауэром для собственных библиотек. Публичный централизованный репозиторий называется Binstar. Ваши зависимости могут исходить от (или обоих).

Многие ошибочно полагают, что Conda - это только система на основе Python, но на самом деле Conda была создана для собственной упаковки (она не является агностикой языка). У этого есть огромное присутствие Python просто потому, что его оригинальная мотивация заключалась в том, чтобы преодолеть страшную поддержку родной библиотеки в другой системе упаковки Python (pip + pypi).

Единственная проблема с Conda в настоящее время заключается в том, что Binstar (центральный репозиторий) пока не имеет каждого пакета. Вы обязательно столкнетесь с отсутствующими библиотеками, которые вам нужны, но это легко исправить: вы можете создать любой пакет, который вам нравится, и нажать его в Binstar. Я должен был сделать это для десятков локальных библиотек. Он работает достаточно хорошо.

Я никогда не вернусь к менеджерам системных зависимостей при разработке кода на С++.

Ответ 5

Это вряд ли произойдет просто потому, что разные библиотеки С++ часто используют VASTLY разные системы сборки. Примерами являются Autoconf, scons, make, MSBuild, VCBuild, Boost Jam, CMake, NMake и QMake. Кроме того, многие разработчики C и С++ генерируют код с помощью таких инструментов, как Yacc и Bison.

Maven и NuGet работают так, как они делают, потому что они поддерживают экосистемы с относительно небольшими вариациями в инструментах построения. Ant в случае Maven, MSBuild в случае NuGet. Создание подобной системы для работы с огромным набором систем сборки С++, которые будут использоваться, было бы невозможно и нецелесообразно (учитывая кажущуюся нехватку спроса на такие системы).

Ответ 6

Существует предложение модуля Daveed, которое didn & rsquo; t превратило его в С++ 0x.

Ответ 7

Я работаю над кросс-платформенным и кросс-архитектурным распределенным диспетчером пакетов. Все пакеты устанавливаются в каталоге проекта (немного как работает nodejs). Это незавершенное производство.

Ответ 8

Существует CoApp, который, похоже, поддерживает Microsoft.

Ответ 9

ryppl, похоже, делает то, что вам нужно, и многое другое, перекрестная платформа:

Наша миссия - создать условия для создания портативной, модульной экосистемы программного обеспечения на С++.

Уже сняли их на GitHub: https://github.com/ryppl/ryppl