réécriture

Merci @miguelvanhove pour l'accès au repo. Je vois que tu as regardé le contenu de cpc-dev-tool-chain, notamment les options pour compiler SDCC (avec juste les modules intéressants pour le Z80) et repris les lignes pour extraire les adresses du log de hex2bin ou sdcc. Et tu as écrit un court script en remplacement du sdcc-project.Makefile.

C'est très minimal, j'apprécie beaucoup les choses minimales. C'est comme ça que cpc-dev-tool-chain a commencé. cptc est comme une réécriture en piochant quelques pourcents de l'existant.

cpc-dev-tool-chain, qualités, défauts

J’ai essayé divers environnements de developpement tels que CPCtelera, cpc-dev-tool-chain mais aucun ne m’a satisfait à 100%.

Ce serait très intéressant si tu pouvais détailler un peu. cpc-dev-tool-chain a plein de fonctionnalités avancées, mais un peu comme un couteau suisse tu vois plein de lames sans trop savoir à quoi elles servent de si formidable. Je le maintiens un peu comme je contribuerai à un projet tiers : en regardant dans l'historique git comment les fonctionnalités ont été ajoutées, par exemple Integrate exomizer. · cpcitor/cpc-dev-tool-chain@8583e4d . Rasm est un ajout récent par exemple. Tout est architecturé autour de make, donc confortable si on connaît make : "j'explique comment transformer un fichier source X en fichier Y, et l'outil se débrouillera tout seul pour arriver au but".

Cela fait quelques temps que j'envisage de réécrire cpc-dev-tool-chain avec d'autres outils avec une approche complètement différente. L'écriture actuelle est conçue dans l'idée de dépendre du moins de choses possibles, et de choses universellement disponibles (type gcc, make). Maintenant que Docker est répandu c'est plus souple, c'est un bon moment pour revoir. Je verrai quand j'aurai un peu de temps...

cpcrslib

Je pensais que cpcrslib était considéré comme surpassé par CPCtelera.

Note pour ceux qui n'ont pas testé, cpcrslib est supporté par cpc-dev-tool-chain aussi : dès qu'un des fichiers C du projet fait un #include de cpcrslib, la toolchain ajoute automatiquement les chemins pour l'étape compilation et l'étape édition de liens.

cptc ?

@miguelvanhove quel avenir vois-tu pour cptc ? Est-ce un outil pour toi que tu partages par transparence ? Quelque chose que tu souhaites développer, mettre en avant, documenter, différent de ce qui existe ? (Une des forces de CPCtelera est le gros travail de documentation. Je trouve que CPCtelera est alourdi par certains choix qui ont été faits, mais au moins c'est très bien documenté.)

Fiou, je pose beaucoup de questions... 🙂

Ehéh.. Mes réponses dans le désordre:

• Je n'ai aucune idée de l'avenir du cptc. Actuellement, je l'ai mis sur GitHub juste par transparence. Pour expliquer mon process de développement dans BriXen. Chaque mise à jour du toolchain peut casser la compatibilité avec un ancien projet et je ne mettrai pas de numéro de version du toolchain (et donc, je ne conseille pas de l'utiliser)
• Pour cpcrslib, comme tu as vu, il n'est pas dans le toolchain mais dans le projet template. Je m'en sers juste comme étant un repository de fonction ASM pouvant accélerer l'éxecution de mon code. Si je trouve une fonction dans la cpctelera, je ferais un extract de cette fonction (si c'est possible) et l'utiliserai aussi.
  Et c'est justement pour ça que j'utilise cpcrslib, une fonction peut-être retirée de son contexte facilement. Après, j'avoue ne pas bien connaitre cpctelera même si leur documentation est effectivement bien faite (rien que la description du temps machine pris par une fonction est déjà excellent). 
• Pour cpc-dev-tool-chain, je le trouvais trop verbeux et pas facile à intégrer à mon flux de developpement avec Visual Studio code. Il me fallait facilement pouvoir compiler mon projet et avoir un retour des mes erreurs lors de la compilation. Après, il est excellent et à conseiller pour les personnes à la recherche de rigueur. 
  Je suis effectivement parti de ton travail pour cdtc et du dockerfile que je t'avais envoyé (9 décembre 2019) pour faire le docker Crazy Piri ;). Si je n'étais plus dans l'urgence du developpement de BriXen, j'aurai du approfondir ton toolchain. Je ne suis pas convaincu de l'utilité de multiplier les environnements de developpement sur Amstrad. Nous ne sommes pas assez de développeurs que pour disperser tout le monde.
• Pour l'utilisation du make, je l'ai retiré parce que je ne le connais pas assez que pour faire des scripts complexes. (Mais je l'utilise dans CrocoDS :p)