Lionel Debroux (./244) :
* je maîtrise suffisamment Perl (appris en-dehors de la fac, d'ailleurs, malheureusement...) pour faire, avec plus de facilité d'écriture qu'en Delphi ou C++, et en profitant de la profondeur de CPAN (plusieurs modules qui parcourent une arborescence de fichiers déjà tout prêts), un outil qui sait mettre des chemins complets partout.

Sauf que la bonne solution, c'est de ne devoir mettre des chemins complets nulle part, pas partout. Et aussi convertir automatiquement les références à _ROM_CALL_nnn vers le vrai nom quand il est connu. Et pour ça, il faut la refonte prévue du système de documentation.

-tu ne sais pas +tu n'as pas réfléchi.
Non seulement plusieurs ont posté dans ce topic, mais il y en a au moins un qui devrait t'être évident, avec ce que j'ai écrit dans ./227...

Je sais très bien réfléchir, mais je ne veux accuser personne sans preuves irréfutables. (Je soupçonne 3 personnes sans te compter, mais je ne ferai pas de noms sans preuves.)

Je pense qu'il serait malin d'ajouter un mode de compatibilité avec la syntaxe classique Motorola à GNU as.

Et qui le code? Il y a un mode --mri-compat qui fait certaines de ces choses, mais il est loin de gérer toutes les bizarreries de A68k. La mythique "syntaxe classique Motorola" n'existe pas, les assembleurs sont tous différents, il y a apparemment des différences subtiles entre les assembleurs MRI et A68k (à moins que le mode --mri-compat ne soit incomplet).

Tiens, stdint.h / inttypes.h... Je les avais oubliés, ceux-là.

Pour avoir une implémentation mergeable de ces headers, il faudra un fichier .hsf pour chaque type déclaré, avec tous les "See Also" qu'il faut. Ça me prend 5 minutes d'écrire juste un header, ce n'est pas du tout ça, le travail.

Mouais... lock-in en théorie, à la limite, mais en pratique, quelqu'un va s'amuser à développer un nouveau 'kernel' pour TI-68k ? Allons donc

Tu ne peux pas prévoir le futur. On disait la même chose avec PreOs 0.67, puis est venue la Titanium, PreOs n'a pas été porté assez rapidement et TitaniK, puis Iceberg ont été créés. Même si on ignore TitaniK qui est un peu particulier, je signale que l'identifiant kernel de Iceberg est 'IC', pas 'PO'.

Vu que je vérifie le contenu des commits avant de propager sur le miroir (pour vérifier que le diff-er de dumpfiles SVN que j'ai écrit ne fait pas n'importe quoi), tu te donnerais de la peine pour rien

Une erreur subtile, genre une faute de frappe dans un nom de variable ou un petit mixup de = et ==, voire carrément une erreur logique indétectable par le compilateur, ça se glisse rapidement, et je ne suis pas sûr que tu arrives à détecter ça avant d'avoir rendu ton code bogué ou non compilable, et je pourrai toujours faire semblant d'avoir fait une erreur, corriger le problème, et en introduire un autre encore plus subtil dans le prochain commit.

squalyl (./245) :
pourissage complet de repository en cas de problème de commit

Jamais vu ça, et visiblement Fedora n'a jamais eu ce problème avec leur CVS pour les paquetages.