Safe Unity Builds

Question

Je travaille sur un grand projet C++ qui utilise des builds Unity. Pour ceux qui ne sont pas familiers avec la pratique, Unity construit #include plusieurs fichiers d'implémentation C++ liés dans une grande unité de traduction qui est ensuite compilée en un seul. Cela évite de recompiler les en-têtes, réduit les temps de liaison, améliore la taille/performance des exécutables en apportant plus de fonctions dans les liens internes, etc.

Cependant, j'ai juste attrapé un bogue latent dans une de nos constructions. Un fichier d'implémentation a utilisé la bibliothèque sans inclure le fichier d'en-tête associé, mais il a été compilé et exécuté. Après m'être gratté la tête pour peu, j'ai réalisé qu'il était inclus par un fichier d'implémentation inclus avant celui-ci dans notre build unité. Aucun mal fait ici, mais cela aurait pu être une surprise embarrassante si quelqu'un avait essayé de réutiliser ce fichier plus tard de façon indépendante.

Existe-t-il un moyen d'intercepter ces dépendances silencieuses tout en conservant les avantages des constructions Unity en plus de générer périodiquement la version non-Unity?

Answer 1

J'ai utilisé des approches UB auparavant pour des projets gelés dans notre référentiel source que nous n'avions jamais prévu de maintenir à nouveau. Malheureusement, je suis certain que la réponse à votre question est non. Vous devez construire périodiquement tous les fichiers cpp séparément si vous voulez tester ces types d'erreurs. Probablement la solution la plus proche d'une solution automagique est un buildbot qui rassemble automatiquement tous les fichiers cpp dans un projet (à l'exception de vos fichiers UB) et construit régulièrement la manière régulière à partir du référentiel source, en soulignant toute erreur de construction dans l'intervalle. De cette façon, votre développement local est toujours rapide (en utilisant des UB), mais vous pouvez toujours attraper les erreurs que vous manquez d'utiliser une construction d'unité à partir de ces buildbot périodiques qui construisent tous les cpps séparément.

Answer 2

Je suggère de ne pas utiliser Unity Build pour votre environnement de développement local. Unity Build ne vous aidera pas à améliorer le temps de compilation lorsque vous éditez et compilez quand même. Utilisez Unity Build uniquement pour votre système de construction continue non incrémentiel, dont vous n'êtes pas censé utiliser la production.

Tant que tous les changements de validation après avoir compilé localement, la situation que vous avez décrite ne devrait pas apparaître.

Et Unity Build peut entraîner des appels de surcharge inattendus entre des fonctions définies localement qui utilisent des noms dupliqués. C'est dangereux et vous n'êtes pas au courant de cela, c'est-à-dire qu'aucune erreur de compilation ou avertissement ne peut être généré dans un tel cas. Sauf si vous avez un moyen d'empêcher cela, veuillez ne pas répondre sur la production générée par Unity Build.