Como os gerenciadores de pacotes do Linux lidam com os módulos C ++ 20?

Estamos em 2020 agora e o C ++ 20 está chegando, juntamente com o tão esperado recurso de módulos C ++. Mas depois de assistir a algumas palestras sobre CppCon, acho que os módulos C ++ estão em um lugar estranho, especialmente para gerenciadores de pacotes Linux (pacman, apt, emerge, etc ...)

Pelo que aprendi, os módulos C ++ são

Dependente do compilador
- Você não pode usar um módulo criado pelo GCC em Clang
- Os módulos do GCC 9.1 não funcionam no GCC 9.2
Você pode ter muitas versões diferentes do mesmo módulo
- Desde que não sejam exportados para o mesmo escopo
Você precisa reconstruir um módulo se suas dependências forem atualizadas

Meu problema é que, em todas as distros de lançamento contínuo, os compiladores são atualizados o tempo todo e o usuário pode ter sua própria compilação. Atualmente, pode-se apenas atualizar o compilador ou também atualizar libstdc++. Mas com os módulos, parece sugerir que libstdc++precisa ser atualizado quando o compilador for atualizado.

Como o gerenciador de pacotes lidaria com a atualização, por exemplo, do STL quando o compilador é atualizado? Não acho que seja viável criar todas as versões do módulo STL para todas as versões do compilador. O usuário também não precisa criar seu próprio módulo STL.

— Mary Chang
fonte

" Você não pode usar um módulo criado pelo GCC no Clang " Você não pode usar os resultados compilados de um módulo criado pelo GCC no Clang.

— Nicol Bolas

Não consigo entender o problema. É possível distribuir os arquivos do módulo pré-compilado, mas isso não é obrigatório. Todo usuário pode compilá-los uma vez para cada compilador / versão e está tudo bem. Se o pacote de distribuição entregar esses arquivos pré-compilados, ele salvará apenas uma única compilação que fazemos atualmente em todas as compilações. Onde está o benefício de entregar módulos pré-compilados? O download / instalação pode demorar mais tempo como a compilação uma vez.

— Klaus

Que tipo de resposta você imagina que não seria pura especulação?

— n. 'pronomes' m.

@Klaus Exatamente, não há benefício. Mas a maioria dos aplicativos é dividida em duas partes. Uma interface e a lib principal. Para que as pessoas possam interagir diretamente com a funcionalidade principal. Tome yosys por exemplo. É cuspido em libyosys e yosys. Se a libyosys decidir usar módulos para compilações mais rápidas, a libyosys deverá ser criada por cada usuário. Transformando efetivamente todo gerenciador de pacotes em AUR ou emergir.

— Mary Chang

@ n.'pronouns'm. Eu esperava que um desenvolvedor de gerenciador de pacotes visse a pergunta e explicasse como eles estão resolvendo o problema.

— Mary Chang

Por enquanto (10 / jan / 2020), o sistema de módulos é considerado mais um recurso interno do projeto do que uma substituição da distribuição de cabeçalho / lib. Como sugerem os caras da comunidade Clang, embora exista uma proposta para criar um formulário AST independente do compilador, nem Clang, nem Gcc nem a Microsoft planejam fazer isso. Então você adivinha

Você pode ter muitas versões diferentes do mesmo módulo

está certo e vai ficar parado por algum tempo.

Como o aspecto da plataforma de gerenciamento de pacotes, a resolução ainda é desconhecida, mas como o sistema de módulos é mais um recurso interno do projeto, o pior caso é que a maneira "header / lib" ainda ocorrerá.

PS Eu acho que o stackoverflow não é um bom lugar para perguntas como estas, se você realmente quer uma resposta, pergunte a esta lista de e-mails.

— ravenisadesk
fonte