Dlaczego nie ma systemów zarządzania pakietami dla C i C ++? [Zamknięte]

Istnieje kilka języków programowania, dla których istnieje system zarządzania pakietami:

• CTAN dla TeX
• CPAN dla Perla
• Pip i jajka dla Pythona
• Maven dla Java
• Cabal dla Haskell
• Klejnoty dla Ruby
• npm dla NodeJS
• altana do frontendu Javascript i CSS
• nuget dla C #
• kompozytor dla PHP

Czy istnieją inne języki z takimi systemami? Co z C i C ++? (to jest główne pytanie!) Dlaczego nie ma dla nich takich systemów? I to nie jest tworzenie pakietów dla yum, apt-getlub innych systemów zarządzania ogólnego pakietu lepiej?

W rzeczywistości niektóre osoby (o zauważalnej sławie doładowującej ) ciężko pracują nad stworzeniem i stworzeniem takiego systemu o nazwie Ryppl . Trudno jest stworzyć taki system dla C ++, ponieważ nie ma on jednego gracza, który mógłby go dyktować. - AKTUALIZACJA: Niestety została porzucona.

W drugim pytaniu zwykły menedżer pakietów (poza tym, że nie jest wieloplatformowy), nie obsługuje specyficznych potrzeb programistów.

Myślę, że problem z C, a jeszcze bardziej z C ++, polega na tym, że są one bardziej heterogenicznymi językami: mimo że języki te są znormalizowane, istnieją różne kompilatory z różnymi opcjami lub różnymi zestawami obsługiwanych funkcji. Np. Pamiętam, że opublikowałem pytanie o przepełnienie stosu w C ++ na przykładzie, który działał doskonale na GCC / Linux i ktoś natychmiast opublikował odpowiedź, mówiąc, że mój kod jest niestandardowy.

Posiadanie systemu pakietów takiego jak te wspomniane w pytaniu oznaczałoby posiadanie wspólnego języka i bibliotek, które są obsługiwane jednorodnie przez wszystkie główne kompilatory we wszystkich popularnych systemach operacyjnych. Na przykład, nie chcesz pobierać pakietu C ++ i odkryć, że nie będzie on kompilował się w twojej wersji kompilatora X, ponieważ został opracowany na kompilatorze Y w innym systemie operacyjnym.

Mógłbym sobie wyobrazić, że system oparty na skryptach make i config (jak powszechnie można znaleźć w Linuksie, cygwinie i innych systemach uniksowych) może działać. Ale dlaczego użytkownicy Visual Studio powinni to przyjąć? To samo dotyczy sytuacji, gdy uruchomiono system pakietów oparty na kompilatorach Microsoft (i bibliotekach).

Fakt, że C ++ jest językiem szybko ewoluującym, a jego standardy zawsze wymagają trochę czasu, zanim zostaną w pełni obsługiwane przez wszystkie kompilatory, nie rozwiązuje problemu.

Myślę, że pytania, które musimy zadać, aby odpowiedzieć na twoje pytanie, brzmią: „Co zyskują inne języki / ekosystemy dzięki swojemu scentralizowanemu repozytorium pakietów?” i „Czy dotyczy to C / C ++?”

Wydaje mi się, że odpowiedź na pierwsze pytanie ma coś wspólnego z początkową promocją nowego języka: pierwsi użytkownicy chcą, aby nowi przybysze mogli jak najłatwiej wejść do ekosystemu, uzyskać użyteczny, przetestowany kod i wnieść własny. Z oczywistych powodów „wykres użytkowania” ma zawsze jeden katalog główny - twórcę (-ów) języka. Zwykle istnieje jedna implementacja referencyjna (przynajmniej początkowo), dlatego każdy kod, który chcesz udostępnić, musi być z nim zgodny.

Ułatwia to tworzenie pakietów, które po prostu pobierają i kompilują. Oczywiście, gdyby C lub C ++ zostały wprowadzone w 2013 roku, ich społeczności mogłyby pójść podobną ścieżką ewolucyjną, ale nie zrobiły tego i nie ma jednego dominującego łańcucha narzędzi, do którego można by zastosować menedżera pakietów. To sprawia, że ​​wdrożenie takiego programu jest zbyt kłopotliwe, aby było warte wysiłku. (powinieneś skłonić użytkowników do wyboru między libfoo-gcc i libfoo-vs? Czy pozostawiasz to programowi pakującemu do rozwiązania? Lub proces kompilacji? Jeśli tak, to w jaki sposób pakiet różni się od zwykłego tarballa?)

Podsumowując moją odpowiedź na pierwsze pytanie, myślę, że wzorzec tworzenia menedżerów pakietów służy głównie do przyspieszenia adopcji .

Mając to na uwadze, myślę, że dość łatwo jest zrozumieć, dlaczego żaden pojedynczy system nie powstał, aby zaspokoić tę potrzebę - ponieważ taka potrzeba nie istnieje dla programistów C i C ++. Problemem dla społeczności C i C ++ (lub jakiejkolwiek społeczności programistów) jest pierwotnie zasugerowana potrzeba: rozpowszechniania, aktualizowania i przekazywania kodu wstecznego. Zostało to rozwiązane wiele razy przez różne osoby o różnym stopniu sukcesu i rzeczywiście jeden system zyskuje znaczący udział w rynku: git (i niektóre inne systemy wcześniej).

Zasadniczo, gdy problemy się różnią, rozwiązania też wyglądają inaczej, ale IMHO różnica między pisaniem gem installa pisaniem git clonejest dyskusyjna.

W tym pytaniu jest trochę zamieszania. Wyżej wymienione oprogramowanie zarządza rozszerzeniami dla określonych języków programowania. Zapewniają biblioteki i kod źródłowy, które mogą być później użyte w twoim programie z wybranym językiem programowania.

Podczas gdy menedżerowie pakietów na poziomie ogólnym zwykle zapewniają pakiety binarne, z których można korzystać niezależnie od aplikacji. Są bardziej zorientowani na system i użytkownika. Oczywiście systemy zarządzania pakietami na poziomie systemu, takie jak Aptitude, rpm, Entropy mogą dostarczyć dowolny pakiet, zarówno binarny, jak i kod źródłowy. Dlatego znajdziesz w nich większość rozszerzeń, które chciałbyś zainstalować z ... Gem na przykład.

Następnie to, co wspomniałeś jako Yum i Apt-get lub Rigo, to po prostu interfejsy użytkownika dla znajdujących się pod nimi systemów zarządzania pakietami.

Jeszcze jedno dla listy języków programowania:

• Kompozytor i Gruszka dla PHP

Zdaję sobie sprawę, że nie jest to rozwiązanie wieloplatformowe, ale należy je dodać do miksu.

CoApp niedawno ogłosił wsparcie dla zarządzania pakietami C ++ przy użyciu NuGet: http://blog.nuget.org/20130426/native-support.html

Obecnie działa to tylko z kompilatorem Visual Studio, ale pojawiło się wiele żądań, aby działało to na innych platformach.