Neden C ve C ++ için paket yönetim sistemleri yok? [kapalı]

78

Paket yönetim sistemi bulunan bazı programlama dilleri vardır:

Bu tür sistemlere sahip başka diller var mı? Peki ya C ve C ++? (asıl soru bu!) Neden onlar için böyle bir sistem yok? Ve yum, apt-getya da diğer genel paket yönetim sistemleri için paket oluşturmak daha iyi değil mi?

c++  c  builds  packages 
— m0nhawk
kaynak
3
Objective-C Cocoapod'lara sahiptir (yakut mücevherlerine ve paketleyiciye çok benzer). Öyle garip ki, C ++ 'ın benzer bir şeyi yok. Belki C ++ daha az homojen olduğundan. Apple, paketleri üzerine inşa etmek için daha standart şeyler sağlar. C ++ 'da hangi string sınıfının kullanılacağına karar veremezsiniz.
— Erik Engheim
Sadece diğer dillerden gelen paket yöneticilerinin mükemmel olmadığını belirtmek isterim. Örneğin, Ruby Gems'te genellikle belirli bir işletim sistemi için çalışmayan bir taşla karşılaşılabilir (olası Windows’tan daha fazla) ve belgeler bu işletim sistemi için çalışmadığını söylemez.
— Travis Pessetto
— Ciro Santilli

Yanıtlar:

28

Aslında bazı insanlar (gözle görülür şekilde artan şöhreti olan) Ryppl adında böyle bir sistemi oluşturmak ve kurmak için çok çalışıyorlar . C ++ için böyle bir Sistem kurmak zordur, çünkü onu dikte edebilecek tek bir oynatıcı yoktur. --UPDATE: Ne yazık ki terk edildi.

İkinci sorunuza göre, normal bir paket yöneticisi (platformlar arası olmamakla birlikte) geliştiricilerin özel ihtiyaçlarını karşılamıyor.

— Fabio Fracassi
kaynak
2
Vay canına, 20 yıl boyunca "Bir paket yöneticisine ihtiyacımız yok!" La nasıl mücadele edeceklerini merak ediyorum.
— TheLQ,
8
Eh, onlar Boost şöhreti olmak, onlara şüphe parasını vereceğim ve bir göz atacağım. Her şeyden önce, Boost oldukça şaşırtıcı :)
— Onno
2
@TheLQ - Daha önce kimsenin uygulanabilir bir çözüm sunmadığı bir şey dışında dövüşecek bir şey olduğunu sanmıyorum. 'Paket yöneticisine kıyamete ihtiyacımız yok' diye bir şey yok 'Kimse bana işe yarar görünen hiçbir şey göstermedi'. İlki dolaşmak zor olabilir, ancak ikincisi basittir: sadece devlerin işlerini yapmasına yardımcı olan bir şey sunun.
— Michael Kohne
1
Bu cevap güncellenmeli: 1) Ryppl ölü bir proje, hatta web sitesi bile ölmüş. 2) cpm gibi başka ticari projeler de (kısa sürede) ortaya çıktı, bu nedenle C ++ 'a paket yöneticisi almak için çok iş yapıldı. 3) Modüller dilde olana kadar kazananın olmayacağına ve araçlardan birinin bundan sonuna kadar yararlanabileceğine inanıyorum.
— Klaim,
2
@Klaim re: {modüller dilde olana kadar} anladığım kadarıyla modüller işleri kolaylaştırmıyor, sadece #includekomut için bir sözdizimi şekeri . Sürüm oluşturma / indirme / yükleme / uyumluluk / platformlar arası C ++ sorunlarının ana sorununu çözmez.
— ruslo
17

C ve C ++ ile ilgili bir problemin onların daha heterojen diller olduğunu düşünüyorum: Bu diller standartlaştırılmış olsalar bile, farklı seçeneklere sahip farklı derleyiciler veya farklı desteklenen özellikler kümeleri var. Örneğin, GCC / Linux üzerinde mükemmel çalışan bir örnekle yığın taşması üzerine C ++ hakkında bir soru gönderdiğimi hatırlıyorum ve birisi derhal kodumun standart olmadığını söyleyen bir cevap gönderdi.

Soruda belirtilenler gibi bir paket sisteme sahip olmak, tüm ortak işletim sistemlerinde tüm büyük derleyiciler tarafından eşit biçimde desteklenen ortak bir dile ve kütüphanelere sahip olmak anlamına gelir. Örneğin, bir C ++ paketini indirmek istemez ve X derleyici sürümünüzde derlenmeyeceğini keşfedersiniz, çünkü başka bir işletim sisteminde derleyici Y üzerinde geliştirilmiştir.

Kod oluşturma ve yapılandırma tabanlı bir sistemin (Linux, cygwin ve diğer Unix lezzetlerinde yaygın olarak bulunur) çalışabileceğini hayal edebiliyorum. Peki neden Visual Studio kullanıcıları bunu benimsemelidir? Aynı kişi Microsoft Derleyicilere (ve kütüphanelere) dayalı bir paket sistemi başlattığında geçerlidir.

C ++ 'nın hızlı gelişen bir dil olması ve standartlarının her zaman tüm derleyiciler tarafından tam olarak desteklenmesinden biraz zaman alması sorunu hafifletmez.

— Giorgio
kaynak
Peki, taşınabilir C ++ yazabilir veya belirli bir alet zincirine yazabilirsiniz. Seçiminiz ve her ikisinde de yanlış olan bir şey yok, ancak ikincisine bir avantaj olmadığında birincisini yapmamak biraz alt düzeydedir.
— Deduplicator
2
Taşınabilir C ve C ++ var. Bir kütüphane kolayca bir yükleyici tarafından tek başına yüklenemiyorsa, yeniden düzenlenmelidir. Bunu başarmak tamamen mümkün. NodeJS'de bile birçok modül Windows'ta yapılamaz, ancak hala varlığını yönetir, bu nedenle zaman zaman oluşturma sorunları bir sorun değildir ve merkezi bir paket yöneticisine sahip olmak kullanıcılardan gelen geri bildirimleri kolaylaştırır ve sorunlarla başa çıkmayı daha teşvik eder.
— Dmitry,
4

Sizinkine cevap vermek için sormamız gereken soruların "Diğer diller / ekosistemlerin kendi merkezi paket havuzuna sahip olmalarından ne kazanıyorlar?" ve "Bu, C / C ++ için geçerli mi?"

İlk sorunun cevabının yeni bir dilin ilk tanıtımıyla bir ilgisi olduğunu hissediyorum: ilk evlat edinenler, yeni gelenlerin ekosisteme girmelerini, faydalı, test edilmiş kodlar edinmelerini ve kendilerine geri katkıda bulunmalarını mümkün olduğunca kolaylaştırmak istiyor. Belli nedenlerden dolayı, "kullanım grafiği" her zaman tek bir kökü vardır - dilin yaratıcısı (ları). Genellikle bir referans uygulaması vardır (en azından başlangıçta) ve bu nedenle paylaşmak isteyebileceğiniz herhangi bir kodun buna uyması gerekir.

Bu, sadece indirip derleyen paketleri oluşturmayı kolaylaştırır. Kuşkusuz, C veya C ++ 2013'te tanıtıldıysa, toplulukları benzer bir evrim yolunu izlemiş olabilirdi, ancak bir paket yöneticisini uygulamak için tek bir hakim araç zinciri yoktu ve yoktu. Bu, böyle bir programın uygulanmasını zahmete değmeyecek kadar zahmetli kılar. (Kullanıcıların libfoo-gcc ve libfoo-vs arasında seçim yapmasını sağlamalı mıyım? Çözmek için paketleyiciye mi bıraktın? Ya da yapım süreci?

İlk soruya verdiğim cevabı özetlemek için, paket yöneticileri oluşturma modelinin çoğunlukla evlat edinmeye yardımcı olduğunu düşünüyorum .

Bunu göz önünde bulundurarak, neden bu ihtiyacı karşılamak için tek bir sistemin neden yükselmediğini görmek oldukça kolay - çünkü ihtiyaç C ve C ++ programcıları için mevcut değil. C ve C ++ topluluğu (ya da herhangi bir programcı topluluğu için) gerçekten bir sorun teşkil eden şey, aslen ima edilen ihtiyaçtır: dağıtmak, güncel tutmak ve geri kod eklemek. Bu, farklı derecelerde başarılı insanlar tarafından birçok kez çözüldü ve gerçekten de bir sistem önemli pazar payı kazanıyor: git (ve bundan önceki diğer sistemler).

Sorunlar farklılık Temelde zaman, çözüm çok farklı görünüyor, ama IMHO yazarak arasındaki fark gem installve git clonetartışmaya açıktır.

— idoby
kaynak
2
"Diğer diller / ekosistemler kendi merkezileştirilmiş paket havuzlarına sahip olmaktan ne kazanıyor?" Paketleri indirmeye ve yazılımınızla düzgün çalışacaklarına güvenmeye başlamak için çok deneyimli bir geliştirici olmanız gerekir. Paket yöneticisine sahip olmak, içeriğe duyarlı derleme yönergeleriyle uğraşmak yerine insanların paketleri kullanmaya başlamasını sağlar. MinGW'de nasıl çalışacağımı nasıl artıracağımı kendim bulamıyorum, bu yüzden işlevselliklerinin çoğunu sadece kullanmak yerine tekrar tekrar kendim yazıyorum. Olmaması aptalca.
— Dmitry,
1
Çeşitli yükleme / derleme komut dosyaları ve bayrakları ile mücadele etmek zorunda kalmamak büyük bir kazanç olacaktır.
— themihai
3

Bu soruda biraz karışıklık var. Yukarıda belirtilen yazılım, belirli programlama dilleri için uzantıları yönetir. Programlamada seçtiğiniz programlama diliyle birlikte kullanabileceğiniz kütüphaneler ve kaynak kodları sağlarlar.

Genel sistem seviyesi paket yöneticileri ise uygulamadan bağımsız olarak kullanılabilecek ikili paketler sağlar. Daha sisteme ve kullanıcıya yönelirler. Tabii ki, Yetenek, rpm, Entropy gibi sistem düzeyinde paket yönetim sistemleri , ikili ya da kaynak kod olarak herhangi bir paket sağlayabilir . Bu yüzden bunlarla birlikte kuracağınız eklentilerin çoğunu bulacaksınız ... Gem .

Dahası, Yum ve Apt-get veya Rigo olarak bahsettiğiniz şey, altlarındaki paket yönetim sistemleri için sadece kullanıcı arayüzleridir.

Programlama dilleri listesi için bir tane daha:

  • PHP için Besteci ve Armut
— Patkos Csaba
kaynak
Evet kesinlikle. Son üç soruyu yazarken ne düşünüyordum?
— m0nhawk 20:12
Mesele şu ki, bu paketler yerelden ziyade küreselleşiyor ve projenizin bağımlılıklarının tek bir klasörde toplanması çok zor. Bu, bir projenin sisteminizde çalışabileceği anlamına gelir, ancak başka bir sisteme koyar yerleştirmez, neye bağlı olduğunu hatırlamanız ve hepsini almanız ve bunları projenizin beklediği yerlere tam olarak koymanız gerekir. Bu süreç cehennemdir. Buna bir örnek GTK, küresel olarak kurulumu kolay, yerel olarak kurulumu zor.
— Dmitry,
0

Bunun bir çapraz platform çözümü olmadığını biliyorum, ancak karışıma eklenmesi gerekiyor.

CoApp kısa bir süre önce NuGet kullanarak C ++ paket yönetimi desteğini açıkladı: http://blog.nuget.org/20130426/native-support.html

Bu şu anda yalnızca Visual Studio derleyicisiyle çalışıyor, ancak bunun diğer platformlarda çalışmasını sağlamak için birçok istek var.

— Joe
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.