Comment les gestionnaires de packages Linux géreraient-ils les modules C ++ 20?

Nous sommes en 2020 maintenant et C ++ 20 arrive, avec la fonctionnalité tant attendue des modules C ++. Mais après avoir regardé quelques discussions sur CppCon, je trouve que les modules C ++ sont dans un endroit étrange, en particulier pour les gestionnaires de paquets Linux (pacman, apt, emerge, etc ...)

D'après ce que j'ai appris, les modules C ++ sont

Dépendant du compilateur
- Vous ne pouvez pas utiliser un module construit par GCC dans Clang
- Les modules GCC 9.1 ne fonctionneront pas sur GCC 9.2
Vous pouvez avoir plusieurs versions différentes du même module
- Tant qu'ils ne sont pas exportés dans le même périmètre
Vous devez reconstruire un module si ses dépendances sont mises à jour

Mon problème est que, dans tous les compilateurs de distributions à diffusion continue, les mises à jour sont constamment mises à jour et l'utilisateur peut avoir sa propre version du compilateur. Actuellement, on peut simplement mettre à jour le compilateur ou aussi mettre à jour libstdc++. Mais avec les modules, il semble suggérer qu'il libstdc++doit être mis à jour lors de la mise à jour du compilateur.

Comment le gestionnaire de packages gérerait-il la mise à jour, par exemple, la STL lors de la mise à jour du compilateur? Je ne pense pas que la construction de chaque version du module STL pour chaque version du compilateur soit possible. L'utilisateur ne doit pas non plus construire son propre module STL.

— Mary Chang
source

" Vous ne pouvez pas utiliser un module construit par GCC dans Clang " Vous ne pouvez pas utiliser les résultats compilés d'un module construit par GCC dans Clang.

— Nicol Bolas

Je ne peux pas attraper le problème. Il est possible de distribuer les fichiers de module précompilés, mais ce n'est pas un must. Chaque utilisateur peut les compiler une fois pour chaque compilateur / version et tout va bien. Si le package distro fournit ces fichiers précompilés, il n'enregistre qu'une seule compilation, ce que nous faisons actuellement à chaque compilation. Où est l'avantage de fournir des modules précompilés? Le téléchargement / l'installation peut prendre plus de temps que la compilation une fois.

— Klaus

Quel genre d'avocat envisagez-vous qui ne serait pas de la pure spéculation?

— n. «pronoms» m.

@Klaus Exactement, il n'y a aucun avantage. Mais la plupart des applications sont divisées en 2 parties. Une interface et le noyau lib. Les utilisateurs peuvent ainsi interagir directement avec la fonctionnalité principale. Prenez par exemple yosys. Il est craché en libyosys et yosys. Si libyosys décide d'utiliser des modules pour des constructions plus rapides, libyosys doit être construit par chaque utilisateur. Transformer efficacement chaque gestionnaire de packages en AUR ou émerger.

— Mary Chang

@ n.'pronouns'm. J'espérais qu'un développeur de gestionnaire de paquets verrait la question et expliquerait comment il résout le problème.

— Mary Chang

Pour l'instant (10 janvier 2020), le système de modules est considéré davantage comme une fonctionnalité interne au projet plutôt que comme un remplacement de la distribution header / lib. Comme le suggèrent les gars de la communauté de Clang, bien qu'il soit proposé de créer un formulaire AST indépendant du compilateur, ni Clang, ni Gcc, ni Microsoft n'ont prévu de le faire. Donc vous devinez

Vous pouvez avoir plusieurs versions différentes du même module

a raison et restera immobile pendant un certain temps.

En tant qu'aspect de la plate-forme de gestion de packages, la résolution est encore inconnue, mais comme le système de modules est davantage une fonctionnalité interne au projet, le pire des cas est que la méthode "header / lib" aura toujours lieu.

PS Je pense que stackoverflow n'est pas un bon endroit pour des questions comme celles-ci, si vous voulez vraiment une réponse, demandez à cette liste de diffusion.

— ravenisadesk
source