Existem algumas linguagens de programação para as quais existe um sistema de gerenciamento de pacotes:
Existe algum outro idioma com esses sistemas? E quanto a C e C ++? (essa é a questão principal!) Por que não existem tais sistemas para eles? E não é melhor criar pacotes para yum , apt-get ou outros sistemas gerais de gerenciamento de pacotes?
Na verdade, algumas pessoas (de notável fama) estão trabalhando duro para criar e estabelecer um sistema chamado Ryppl . É difícil estabelecer um sistema desse tipo para o C ++, porque ele não possui um único player que possa ditá-lo. --UPDATE: Infelizmente é abandonado.
Na sua segunda pergunta, um gerenciador de pacotes normal (além de não ser multi-plataforma) não atende às necessidades específicas dos desenvolvedores.
Eu acho que um problema com C e ainda mais com C ++ é que eles são linguagens mais heterogêneas: embora essas linguagens sejam padronizadas, existem compiladores diferentes com opções diferentes ou conjuntos diferentes de recursos suportados. Por exemplo, lembro de postar uma pergunta sobre o C ++ no estouro de pilha com um exemplo que funcionava perfeitamente no GCC / Linux e alguém imediatamente postou uma resposta dizendo que meu código não era padrão.
Ter um sistema de pacotes como os mencionados na questão implicaria ter uma linguagem e bibliotecas comuns que sejam suportadas uniformemente por todos os principais compiladores em todos os sistemas operacionais comuns. Por exemplo, você não deseja baixar um pacote C ++ e descobrir que ele não será compilado em sua versão do compilador X porque foi desenvolvido no compilador Y em outro sistema operacional.
Eu poderia imaginar que um sistema baseado em scripts make e configure (como comumente encontrados em Linux, cygwin e outros tipos de Unix) poderia funcionar. Mas por que os usuários do Visual Studio devem adotá-lo? O mesmo é válido se você iniciar um sistema de pacotes baseado nos Compiladores da Microsoft (e bibliotecas).
O fato de o C ++ ser uma linguagem em rápida evolução e seus padrões sempre levarem algum tempo antes de ser totalmente suportado por todos os compiladores não alivia o problema.
Acho que as perguntas que precisamos fazer para responder a sua pergunta são: "O que outros idiomas / ecossistemas ganham por ter seu próprio repositório centralizado de pacotes?" e "Isso se aplica ao C / C ++?"
Eu sinto que a resposta para a primeira pergunta tem algo a ver com a promoção inicial de uma nova linguagem: os primeiros adotantes querem que seja tão fácil quanto possível para os recém-chegados entrarem no ecossistema, adquirirem código útil e testado e contribuírem de volta. seus próprios. Por razões óbvias, o "gráfico de uso" sempre tem uma única raiz - o (s) criador (es) da linguagem. Geralmente, há uma implementação de referência (pelo menos inicialmente) e, portanto, qualquer código que você queira compartilhar tem que estar de acordo com ela.
Isso facilita a criação de pacotes que apenas baixam e compilam. Certamente, se C ou C ++ tivessem sido introduzidos em 2013, suas comunidades poderiam ter seguido um caminho evolucionário similar, mas eles não o fizeram e não há uma única cadeia de ferramentas prevalecente para aplicar um gerenciador de pacotes. Isso torna a implementação de tal programa muito problemática para valer a pena. (você deve fazer os usuários escolher entre libfoo-gcc e libfoo-vs? Você deixa para o empacotador resolver? Ou o processo de compilação? Se sim, como um pacote é diferente de um tarball direto?)
Então, para resumir minha resposta à primeira pergunta, acho que o padrão de criação de gerenciadores de pacotes serve principalmente para impulsionar adoção .
Com isso em mente, acho que é bem fácil perceber por que nenhum sistema único surgiu para atender a essa necessidade - porque não existe necessidade de programadores C e C ++. O que constitui um problema para a comunidade C e C ++ (ou qualquer comunidade de programadores, na verdade) é a necessidade originalmente implícita: distribuir, manter-se atualizado e contribuir com código de volta. Isso foi resolvido muitas vezes por pessoas diferentes com vários graus de sucesso e, de fato, um sistema está ganhando uma participação de mercado significativa: git (e alguns outros sistemas antes disso).
Basicamente, quando os problemas diferem, as soluções parecem diferentes também, mas IMHO a diferença entre digitar gem install e git clone é irrelevante.
Há uma pequena confusão nesta questão. O software acima mencionado gerencia extensões para linguagens de programação específicas. Eles fornecem bibliotecas e código-fonte que depois podem ser usados em seu programa com sua linguagem de programação preferida.
Embora os gerenciadores de pacotes de nível geral do sistema geralmente forneçam pacotes binários que podem ser usados independentemente do aplicativo. Eles são mais orientados para o sistema e usuário. Naturalmente, sistemas de gerenciamento de pacotes no nível do sistema, como Aptitude, rpm, Entropy, podem fornecer qualquer pacote, seja ele código binário ou fonte. É por isso que você encontrará nelas a maioria das extensões que você instalaria com o Gem por exemplo.
Então, o que você mencionou como Yum e Apt-get ou Rigo são apenas interfaces de usuário para os sistemas de gerenciamento de pacotes abaixo deles.
Mais um para a lista de linguagens de programação:
Sei que esta não é uma solução de plataforma cruzada, mas deve ser adicionada ao mix.
A CoApp anunciou recentemente o suporte ao gerenciamento de pacotes C ++ usando o NuGet: link
Atualmente, isso funciona apenas com o compilador do Visual Studio, mas houve muitas solicitações para que isso funcionasse em outras plataformas.