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

78

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

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

m0nhawk
источник
3
Objective-C имеет Cocoapods (очень похоже на рубиновые самоцветы и связки). Так странно, что в C ++ нет ничего похожего. Возможно, потому что C ++ менее однороден. Apple предоставляет больше стандартных вещей для создания пакетов сверху. В C ++ вряд ли можно договориться о том, какой класс строки использовать.
Эрик Энгхайм,
Я просто хотел бы отметить, что менеджеры пакетов из других языков не идеальны. Например, в Ruby Gems часто можно встретить гем, который не работает для конкретной ОС (более вероятно, для Windows), и документация не говорит вам, что он не работает для этой ОС.
Трэвис Пессетто
stackoverflow.com/questions/7266097/…
Сиро Сантилли 新疆 改造 中心 法轮功 六四 事件

Ответы:

28

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

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

Фабио Фракасси
источник
2
Вау, мне интересно, как они собираются сражаться 20 лет "Нам не нужен менеджер пакетов!"
TheLQ
8
Что ж, они имеют славу Повышения, я дам им преимущество сомнения и взгляну. Повышение, в конце концов, довольно удивительно :)
Onno
2
@TheLQ - Я не думаю, что есть с чем бороться, кроме того, что никто ранее не представил работоспособное решение. Нет «нам не нужно не вонять, менеджер пакетов», нет «Никто не показал мне ничего полезного». С первым может быть сложно обойтись, но с вторым все просто: просто представьте что-то, что действительно поможет разработчикам делать свою работу.
Майкл Кохн
1
Этот ответ должен быть обновлен: 1) Ryppl - мертвый проект, даже если его сайт мертв. 2) В последнее время появились другие проекты (коммерческие или нет), такие как cpm, поэтому для получения менеджера пакетов для C ++ проделана большая работа. 3) Я считаю, что победителя не будет, пока модули не будут переведены на язык, и один из инструментов сможет использовать его в полной мере.
Klaim
2
@Klaim re: {пока модули на языке}, насколько я понимаю, модули не делают вещи проще, это всего лишь синтаксический сахар для #includeкоманды. Это не решит основную проблему управления версиями / загрузки / установки / совместимости / кроссплатформенности C ++.
Русло
17

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

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

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

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

Джорджио
источник
Ну, вы можете написать переносимый C ++ или написать для определенного набора инструментов. Ваш выбор, и в этом нет ничего плохого, хотя не делать первое, когда нет преимущества перед вторым, является несколько неоптимальным.
Дедупликатор
2
Есть переносимые C и C ++. Если библиотека не может быть легко установлена ​​автономным способом установщиком, ее следует переделать. Это вполне возможно сделать. Даже в NodeJS многие модули не могут быть собраны в Windows, но все же удается существовать, поэтому случайные проблемы со сборкой не являются проблемой, а наличие централизованного менеджера пакетов упрощает обратную связь с пользователями и делает его более стимулирующим для решения проблем.
Дмитрий
4

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

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

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

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

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

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

idoby
источник
2
«Что получают другие языки / экосистемы, имея собственный централизованный репозиторий пакетов?». Вы должны быть очень опытным разработчиком, чтобы начать загружать пакеты и доверять им для правильной работы с вашим программным обеспечением. Наличие менеджера пакетов позволяет людям просто начать использовать пакеты вместо того, чтобы иметь дело с контекстно-зависимыми инструкциями по сборке / так далее. Я сам не могу понять, как получить импульс для работы над MinGW, поэтому я в конечном итоге сам пишу большую часть его функциональных возможностей, а не просто использую их. Глупо не иметь.
Дмитрий
1
Отсутствие необходимости бороться с различными скриптами установки / сборки и флагами было бы большой победой.
Мехай
3

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

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

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

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

  • Композитор и Груша для PHP
Паткос Чаба
источник
Определенно да. О чем я думал, когда писал последние три вопроса?
m0nhawk
Проблема в том, что эти пакеты распространяются глобально, а не локально, и объединить зависимости вашего проекта в одну папку очень сложно. Это означает, что проект может работать в вашей системе, но как только вы поместите его в другую систему, вам нужно будет помнить, от чего он зависит, и получить все из них, и поместить их в точные места, ожидаемые от вашего проекта. Этот процесс адский. Примером этого является GTK, легко устанавливаемый в глобальном масштабе, трудно устанавливаемый локально.
Дмитрий
0

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

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

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

Джо
источник