Por que não existem sistemas de gerenciamento de pacotes para C e C ++? [fechadas]

78

Existem algumas linguagens de programação para as quais existe um sistema de gerenciamento de pacotes:

Existem outros idiomas com esses sistemas? E quanto a C e C ++? (essa é a questão principal!) Por que não existem sistemas para eles? E não é a criação de pacotes para yum, apt-getou outros sistemas de gestão geral pacote melhor?

c++  c  builds  packages 
— m0nhawk
fonte
3
O Objective-C possui Cocoapods (muito semelhantes às gemas de rubi e bundler). Tão estranho que o C ++ não tem algo parecido. Talvez porque o C ++ seja menos homogêneo. A Apple fornece material mais padrão para criar pacotes ainda por cima. Em C ++, dificilmente se pode concordar com qual classe de string usar.
— Erik Engheim
Gostaria apenas de salientar que os gerenciadores de pacotes de outros idiomas não são perfeitos. Por exemplo, no Ruby Gems, muitas vezes é possível encontrar uma jóia que não funciona para um sistema operacional específico (mais do que provavelmente o Windows) e a documentação não informa que ele não funciona para esse sistema operacional.
— Travis Pessetto
— Ciro Santilli (

Respostas:

28

Na verdade, algumas pessoas (com notável fama de incentivo) estão trabalhando duro para criar e estabelecer um sistema chamado Ryppl . É difícil estabelecer um sistema para C ++, porque ele não possui um único jogador que possa ditá-lo. --UPDATE: Infelizmente foi abandonado.

Na sua segunda pergunta, um gerenciador de pacotes normal (além de não ser multiplataforma) não atende às necessidades específicas dos desenvolvedores.

— Fabio Fracassi
fonte
2
Uau, eu me pergunto como eles vão lutar 20 anos de "Não precisamos de um gerenciador de pacotes!"
— TheLQ
8
Bem, como eles são da fama do Boost, vou dar o benefício da dúvida e dar uma olhada. Boost, afinal de contas, é bastante surpreendente :)
— Onno
2
@TheLQ - Acho que não há nada a combater além do fato de ninguém ter apresentado uma solução viável anteriormente. Não há 'não precisamos fedor' no gerenciador de pacotes '' há 'ninguém me mostrou algo que parece útil'. O primeiro pode ser difícil de contornar, mas o segundo é simples: basta apresentar algo que realmente ajude os desenvolvedores a fazerem seu trabalho.
— 22812 Michael Kohne
1
Esta resposta deve ser atualizada: 1) Ryppl é um projeto morto, mesmo o site está morto. 2) Outros projetos (comerciais ou não) como o cpm surgiram recentemente, portanto há muito trabalho sendo feito para obter um gerenciador de pacotes para C ++. 3) Acredito que não haverá vencedor até que os módulos estejam na linguagem e uma das ferramentas consiga explorar isso ao máximo.
— Klaim
2
@Klaim re: {até que os módulos estejam na linguagem}, até onde eu entendo, os módulos não facilitam as coisas, é apenas um açúcar de sintaxe para o #includecomando. Ele não resolverá o problema principal de versão / download / instalação / compatibilidade / problemas de C ++ entre plataformas.
— Ruslo 03/11/2015
17

Penso que um problema com C e ainda mais com C ++ é que elas 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-me de postar uma pergunta sobre C ++ no estouro de pilha com um exemplo que estava funcionando 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 pergunta implicaria ter uma linguagem e bibliotecas comuns suportadas uniformemente por todos os principais compiladores em todos os sistemas operacionais comuns. Por exemplo, você não deseja baixar um pacote C ++ e descobre que ele não será compilado na 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 de criação e configuração (como comumente encontrado no Linux, cygwin e outros tipos de Unix) poderia funcionar. Mas por que os usuários do Visual Studio deveriam adotá-lo? O mesmo vale se alguém iniciou um sistema de pacotes baseado nos Microsoft Compilers (e bibliotecas).

O fato de o C ++ ser uma linguagem de rápida evolução e seus padrões sempre levar algum tempo antes de ser totalmente suportado por todos os compiladores não alivia o problema.

— Giorgio
fonte
Bem, você pode escrever C ++ portátil ou escrever em uma cadeia de ferramentas específica. Sua escolha e nada de errado com qualquer um deles, apesar de não fazer o primeiro quando não há vantagem para o último, são um pouco abaixo do ideal.
— Deduplicator
2
Há C e C ++ portáteis. Se uma biblioteca não puder ser instalada de forma independente por um instalador facilmente, ela deverá ser refeita. É perfeitamente possível fazer isso. Mesmo no NodeJS, muitos módulos não conseguem compilar no Windows, mas ele ainda existe, portanto problemas ocasionais de compilação não são um problema, e ter um gerenciador de pacotes centralizado otimiza o feedback dos usuários e torna mais incentivo para lidar com problemas.
— Dmitry
4

Acho que as perguntas que precisamos fazer para responder às suas são "O que outros idiomas / ecossistemas ganham por ter seu próprio repositório de pacotes centralizado?" 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 um novo idioma: os primeiros adotantes querem facilitar ao máximo para que os iniciantes entrem no ecossistema, adquiram códigos úteis e testados e contribuam de volta. Por razões óbvias, o "gráfico de uso" sempre tem uma única raiz - o (s) criador (es) do idioma. Geralmente, há uma implementação de referência (pelo menos inicialmente) e, portanto, qualquer código que você queira compartilhar precisa estar em conformidade.

Isso facilita a criação de pacotes que apenas baixam e compilam. Certamente, se C ou C ++ tivesse sido introduzido em 2013, suas comunidades poderiam ter seguido um caminho evolutivo semelhante, mas não o fizeram e não há uma única cadeia de ferramentas predominante para aplicar um gerenciador de pacotes. Isso torna a implementação de um programa muito problemático para valer a pena. (você deve fazer com que os usuários escolham entre libfoo-gcc e libfoo-vs? Você deixa o empacotador resolver? Ou o processo de compilação? Em caso afirmativo, 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 a adoção .

Com isso em mente, acho que é bastante fácil ver por que nenhum sistema único surgiu para atender a essa necessidade - porque a necessidade não existe para programadores de C e C ++. O que constitui um problema para a comunidade C e C ++ (ou para qualquer comunidade de programadores, na verdade) é a necessidade originalmente implícita: distribuir, manter-se atualizado e contribuir com o código de retorno. Isso foi resolvido muitas vezes por pessoas diferentes com graus variados de sucesso e, de fato, um sistema está ganhando participação de mercado significativa: o git (e alguns outros sistemas anteriores a isso).

Basicamente, quando os problemas diferem, as soluções também parecem diferentes, mas IMHO a diferença entre digitar gem installe git cloneé discutível.

— idobia
fonte
2
"O que outros idiomas / ecossistemas ganham por ter seu próprio repositório de pacotes centralizado?". Você precisa ser um desenvolvedor muito experiente para começar a baixar pacotes e confiar neles para funcionar corretamente com seu software. Ter um gerenciador de pacotes permite que as pessoas comecem a usar pacotes em vez de lidar com instruções de construção sensíveis ao contexto, etc. Eu mesmo não consigo descobrir como obter impulso para trabalhar no MinGW, então acabo escrevendo muitas das suas funcionalidades várias vezes, em vez de apenas usá-lo. É bobagem não ter.
— Dmitry
1
Não ter que lutar com vários scripts e sinalizadores de instalação / construção seria uma grande vitória.
— themihai
3

Há um pouco de confusão nessa questão. O software acima mencionado gerencia extensões para linguagens de programação específicas. Eles fornecem bibliotecas e código fonte que posteriormente podem ser usados ​​no seu programa com sua linguagem de programação preferida.

Embora os gerenciadores de pacotes em 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. Obviamente, sistemas de gerenciamento de pacotes em nível de 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 instalaria com ... 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 uma para a lista de linguagens de programação:

  • Compositor e Pear para PHP
— Patkos Csaba
fonte
Sim, definitivamente. O que eu estava pensando quando escrevi as três últimas perguntas?
— M0nhawk #
O problema é que esses pacotes ficam globalmente e não localmente, e agrupar dependências do seu projeto em uma única pasta é muito difícil. Isso significa que um projeto pode funcionar em seu sistema, mas assim que você o coloca em outro sistema, você precisa se lembrar do que depende e obter todos eles e colocá-los nos lugares exatos que seu projeto espera que estejam. Esse processo é um inferno. Um exemplo disso é o GTK, fácil de instalar globalmente, difícil de instalar localmente.
— Dmitry
0

Sei que essa não é uma solução de plataforma cruzada, mas deve ser adicionada à mistura.

A CoApp anunciou recentemente o suporte ao gerenciamento de pacotes C ++ usando o NuGet: http://blog.nuget.org/20130426/native-support.html

Atualmente, isso funciona apenas com o compilador do Visual Studio, mas houve muitas solicitações para que isso funcionasse em outras plataformas.

— Joe
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.