Почему нет систем управления пакетами для C и C ++? [закрыто]

Существует несколько языков программирования, для которых существует система управления пакетами:

• CTAN для TeX
• CPAN для Perl
• Пип и яйца для Python
• Maven для Java
• клика для Хаскелла
• Драгоценные камни для Руби
• НПМ для NodeJS
• Бауэр для внешнего интерфейса Javascript & CSS
• Nuget для C #
• композитор для PHP

Есть ли другие языки с такими системами? А как насчет C и C ++? (это главный вопрос!) Почему для них нет таких систем? И не создают пакеты для yum, apt-getили других систем общего управления пакетами лучше?

На самом деле, некоторые люди (с заметной популярностью) усердно работают над созданием и созданием такой системы, которая называется Ryppl . Трудно создать такую ​​Систему для C ++, потому что в ней нет ни одного игрока, который мог бы ее диктовать. - ОБНОВЛЕНИЕ: К сожалению это заброшено.

На ваш второй вопрос, обычный менеджер пакетов (помимо того, что он не кроссплатформенный) не отвечает специфическим потребностям разработчиков.

Я думаю, что проблема с C и даже больше с C ++ заключается в том, что они являются более разнородными языками: даже если эти языки стандартизированы, существуют разные компиляторы с разными опциями или разными наборами поддерживаемых функций. Например, я помню, как публиковал вопрос о C ++ по переполнению стека с примером, который отлично работал на GCC / Linux, и кто-то сразу же опубликовал ответ о том, что мой код был нестандартным.

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

Я мог бы предположить, что система, основанная на скриптах make и configure (как это обычно встречается в Linux, cygwin и других разновидностях Unix), может работать. Но почему пользователи Visual Studio должны его принять? То же самое действительно, если кто-то запустил систему пакетов на основе компиляторов Microsoft (и библиотек).

Тот факт, что C ++ является быстро развивающимся языком и его стандарты всегда требуют некоторого времени, прежде чем его полностью поддержат все компиляторы, не устраняет проблему.

Я думаю, что для ответа на ваши вопросы нам нужно задать следующие вопросы: «Что получают другие языки / экосистемы, имея собственный централизованный репозиторий пакетов?» и "Применимо ли это к C / C ++?"

Я чувствую, что ответ на первый вопрос как-то связан с первоначальным продвижением нового языка: новички хотят как можно проще для новичков войти в экосистему, приобрести полезный, протестированный код и внести свой вклад. По понятным причинам «граф использования» всегда имеет единственного корня - создателя (ов) языка. Обычно существует одна ссылочная реализация (по крайней мере, на начальном этапе), и поэтому любой код, которым вы можете поделиться, должен соответствовать ей.

Это позволяет легко создавать пакеты, которые просто скачивают и компилируют. Конечно, если бы C или C ++ были введены в 2013 году, их сообщества могли бы пойти по схожему эволюционному пути, но у них не было и нет единого преобладающего набора инструментов, к которому можно было бы применить менеджер пакетов. Это делает реализацию такой программы слишком хлопотной, чтобы стоить хлопот. (следует ли пользователям выбирать между libfoo-gcc и libfoo-vs? Вы оставляете решение для упаковщика? Или процесс сборки? Если да, то чем пакет отличается от обычного тарбола?)

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

Имея это в виду, я думаю, что довольно легко понять, почему ни одна система не возникла, чтобы удовлетворить эту потребность - потому что потребности в программистах на C и C ++ не существует. Что представляет собой проблему для сообщества C и C ++ (или любого сообщества программистов, на самом деле), так это изначально подразумеваемая необходимость: распространять, обновлять и предоставлять код. Это неоднократно решалось разными людьми с разной степенью успеха, и действительно одна система завоевывает значительную долю рынка: git (и некоторые другие системы до этого).

В основном, когда проблемы различаются, решения тоже выглядят по-разному, но ИМХО разница между набором текста gem installи git cloneспорная.

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

В то время как менеджеры пакетов общего системного уровня обычно предоставляют бинарные пакеты, которые можно использовать независимо от приложения. Они больше ориентированы на систему и пользователя. Конечно, системы управления пакетами системного уровня, такие как Aptitude, rpm, Entropy, могут предоставить любой пакет, будь то бинарный или исходный код. Вот почему вы найдете в них большинство расширений, которые вы устанавливаете с ... Gem, например.

Чем то, что вы упомянули как Yum и Apt-get или Rigo, являются просто пользовательскими интерфейсами для систем управления пакетами под ними.

Еще один список языков программирования:

• Композитор и Груша для PHP

Я понимаю, что это не кроссплатформенное решение, но оно должно быть добавлено к смеси.

CoApp недавно объявил о поддержке управления пакетами C ++ с использованием NuGet: http://blog.nuget.org/20130426/native-support.html

В настоящее время это работает только с компилятором Visual Studio, но было много запросов, чтобы заставить это работать на других платформах.