Le code compilé séparé dans LabVIEW, expliqué

« Separate compiled code from source file » déplace le code compilé d'un VI hors du fichier .vi vers un cache d'objets local, de sorte que recompiler un appelant parce que son VI appelé a changé ne réécrit plus l'appelant sur le disque. Cela supprime la plupart des fichiers « modifiés » parasites que Git affiche après un petit changement LabVIEW. Le code compilé séparé ne rend pas les VI diffables, et une compilation de masse touche toujours chaque fichier.

Ce qu'il y a dans un fichier VI

Par défaut, un .vi contient trois choses dans un seul fichier binaire : la face-avant, le diagramme, et le code compilé pour la plateforme et la version de LabVIEW qui l'a enregistré en dernier. La source et le code machine voyagent ensemble.

C'est ce couplage qui produit le bruit. Quand le SubVI B change, LabVIEW recompile chaque appelant A qui est chargé, parce que le code compilé de A dépend du connecteur de B et de son inlining. A est maintenant modifié en mémoire, et l'enregistrer réécrit les octets de A même si personne n'a ouvert le diagramme de A.

Git ne peut pas faire la différence. Il voit quarante fichiers modifiés après l'édition d'un seul VI, et l'historique des commits enregistre un changement de A qui n'a jamais eu lieu dans la source de A.

Ce que le réglage change

Le réglage existe depuis LabVIEW 2010, par VI et par projet. Par VI, il est dans les propriétés du VI, page General. Par projet, il est dans les propriétés du projet, où « Separate compiled code from new project files » s'applique aux fichiers ajoutés à partir de là, et un bouton « Mark Existing Items » l'applique à tout ce qui est déjà dans le projet.

Une fois activé, LabVIEW n'enregistre que la source dans le .vi et écrit le code compilé dans le cache d'objets des VI. Le cache est un répertoire par utilisateur, par version de LabVIEW et par nombre de bits sur la machine locale, dont l'emplacement se règle sous Tools, Options, Environment. Il n'est jamais dans le dépôt, donc un clone frais s'ouvre plus lentement la première fois pendant que le cache se remplit, et une machine de build le reconstruit de zéro.

Les exécutables compilés ne sont pas concernés. L'Application Builder intègre toujours le code compilé dans l'exécutable, donc rien ne change pour le poste.

Les deux pages NI qui décrivent le mécanisme sont séparer le code compilé des VI et des autres types de fichiers et séparer le code compilé pour le contrôle de version.

Ce qui s'améliore dans Git

Le gain est que « modifié » se met à signifier « la source a changé ». Voici ce que Git montre pour les cas courants, avant et après.

Lisez les deux premières lignes comme le gain. Un commit après un changement de limite dans un SubVI contient un seul fichier, ce qui rend l'historique lisible et un revert sûr. La raison pour laquelle cela compte, et tout ce que les fichiers binaires coûtent par ailleurs à une équipe, est dans pourquoi le contrôle de version LabVIEW est si pénible.

Lisez les trois dernières lignes comme la limite. Une mise à niveau de version, un changement de nombre de bits ou une compilation de masse complète réécrivent toujours l'arborescence, et l'historique des changements individuels de part et d'autre de ce commit ne se diffe plus proprement. Mettre à niveau un poste de LabVIEW 2019 vers 2024 planifie autour de ce commit au lieu de faire comme s'il n'existait pas.

Ce qui ne change pas

Le .vi est toujours binaire. Git dit toujours « Binary files differ », git blame nomme toujours un seul auteur pour tout le fichier, et une pull request ne montre toujours rien qu'un relecteur puisse lire.

La fusion ne change pas non plus. Deux personnes qui éditent le même VI sur deux branches ont toujours besoin de LVMerge, qui a besoin du Professional Development System et de la même version de LabVIEW sur la machine qui fait la fusion. Le réglage réduit la fréquence à laquelle deux personnes touchent le même fichier par accident, ce qui aide, mais un vrai conflit se résout toujours comme corriger les conflits de fusion LabVIEW sur des VI binaires le décrit.

Le réglage est une mesure d'hygiène pour le contrôle de version. Elle vaut la peine, et c'est tout ce qu'elle fait.

Comment l'activer sur un projet en toute sécurité

Le basculement touche chaque fichier une fois. Faites-le en une seule séance pour que le bruit atterrisse dans un seul commit.

1. Committez une arborescence propre et taguez-la, pour avoir un point connu avant le changement.
2. Mettez tout le monde sur la même version de LabVIEW et le même nombre de bits. Le cache est de toute façon par version et par nombre de bits, et les mélanger pendant le basculement produit une deuxième vague de fichiers modifiés.
3. Dans les propriétés du projet, cochez « Separate compiled code from new project files », puis utilisez « Mark Existing Items » pour appliquer le réglage à chaque VI, contrôle, classe et bibliothèque déjà dans le projet.
4. Lancez une compilation de masse du projet, depuis Tools, Advanced, Mass Compile, pour que chaque fichier soit enregistré avec le nouveau réglage et une entrée de cache valide.
5. Committez le tout en un seul commit avec un message qui dit ce que c'est, et taguez-le.
6. Dites à Git que les fichiers sont binaires, pour qu'il n'essaie jamais de les differ ou de les fusionner comme du texte.

# Les sources LabVIEW sont binaires : jamais de diff ligne par ligne ni de fusion automatique.*.vi binary*.vit binary*.ctl binary*.ctt binary

À partir du commit suivant, un VI modifié signifie que quelqu'un l'a édité. Un collègue qui tire le commit tagué ouvre le projet, attend que le cache se remplisse, et voit une arborescence propre.

Le commit unique est gros et inutile à relire. Nommez-le clairement, puis traitez-le comme une frontière : git log avant et après sont tous deux lisibles, à travers lui non.

Le cas des classes

Un fichier .lvclass est du XML, mais il porte le contrôle de données privées de la classe aplati à l'intérieur. Une compilation de masse peut réaplatir ce contrôle et changer les octets, donc une classe apparaît modifiée après une compilation de masse même avec le code compilé séparé activé et aucun changement de source nulle part.

Attendez-vous-y, et ne cherchez pas plus loin. Après une compilation de masse, committez les classes avec tout le reste et n'essayez pas de relire ces diffs. En travail normal, une classe qui apparaît modifiée alors que personne ne l'a éditée est le signe qu'un VI membre ou le contrôle de données privées a été recompilé, et elle peut être committée ou abandonnée sans risque.

Le contraste : un dépôt sans aucun code compilé

Un poste Python sous le TofuPilot Framework n'a rien à séparer. Le dépôt contient procedure.yaml, phases/*.py et plugs/*.py, tous en texte, et Git les diffe, les blame et les fusionne sans plugin et sans licence.

L'artefact compilé existe, mais il vit ailleurs. Un push Git crée un déploiement dans TofuPilot, un build immuable de la procedure à ce commit avec un identifiant comme dep_abc123, et le poste le récupère avec tofupilot pull. Le dépôt ne contient jamais que de la source, chaque run uploadé depuis le poste porte le déploiement qui l'a produit, et la compilation de masse n'est pas un concept.

Commencez par un poste

Quand vous déplacez un poste, choisissez celui où le commit de compilation de masse a fait le plus mal, reconstruisez-le en Python avec le TofuPilot Framework, et faites-le tourner à côté de la version LabVIEW sur les mêmes unités pendant deux semaines. Le dépôt de ce poste ne contiendra que de la source.

# Installe le CLI, puis lance le poste en local (sans compte) ou avec upload.curl -fsSL https://www.tofupilot.app/install | shtofupilot run ./procedure.yamltofupilot run ./procedure.yaml --upload

La reconstruction pas à pas est dans comment migrer de LabVIEW vers Python pour les tests de fabrication avec TofuPilot, et le framework lui-même est sur tofupilot.com/products/framework. L'offre Lab est gratuite, et tofupilot run fonctionne sans compte.