[GCC-DEVC++] Compilation de 'PrinterToPDF' en W32.

[Xavier_AL]

Salut,

Projet: Rendre le projet 'PrinterToPDF' disponible sous Windows.

Sources (linux): https://github.com/RWAP/PrinterToPDF
Suivi du projet: https://www.sinclairzxworld.com/viewtop ... f=7&t=3339

https://www.sinclairzxworld.com/viewtop ... f=7&t=3339

A première vue, le projet est simple…
Mais, du côté compilation, ca ce complique.

Je télécharge le projet, les librairies.
- SDL avec sa DLL et libsdl-image1.2.
- LibHaru pour la création des PDFs: http://libharu.org/
- libpng: ImageMagick.

Le tout dans DEV-C++.
… et ça marche pas.


Bon, je retourne préparer ma question, car avec toutes ces librairies il faut que je vérifie que tout soit bien installé.

[gilles]

dev-cpp c''est un très vieux GCC il me semble du coup ça va coincer tout le temps au niveau des libs. (j'ai longtemps utilisé dev-cpp jusqu'au moment où j'ai eu trop de soucis avec).

perso pour faire du binaire windows je préfére rester sous linux et utiliser un gcc récent avec mingw-w64.

[hlide]

mingw-w64 ou visual studio community si l'ensemble des librairies utilisées est portable.

[Xavier_AL]

Salut,

Oui, j'avoue que sur les nouvelles distribs, j'ai trouvé des bogues de compilation… introduits pas l'arrivée du 64bits.
La config par défaut est en 64b, et si l'on passe en 32b... on ce retrouve avec des erreurs à la pelle.
C'est pour cela que je cherche… un problème que j'ai déjà résolu par moi même, il y à quelques mois… mais, j'avais tellement galérer que je ne trouve plus "l'astuce" pour compiler le programme proprement.
A moins d'un coup de bol… je risque de convertir le programme en >VB !


Le problème avec ce type de sources, c'est qu'il est difficile de reconstruire un environnement de compilations regroupant de nombreuses librairies, qui ont évolué en version, en compatibilité et en structure.
A l'instar des utilisations des OCX et DLL en VBasic, les sources sont pratiquement impossibles à reconstruire et recompiler… sans chercher les dépendances "orphelines" non distribuée avec les sources.
Même moi, avec un changement de micro, de système et une réinstallation d'un compilateur, il m'a été difficile de recompiler mes ancients projets.

Entre les paths et les enregistrement de clés qui changent, les compatibilités de système qui refusent l'utilisation de modules…
Je recommande aux "nouveaux" rétro-programmeurs (sur VB6), d'utiliser un minimum de dépendances (OCX) qui rendront un logiciel impossible à recompiler… ou à utiliser! Car certains OCX sont déjà plus utilisables sur les machines actuelles!
Pire, on cumule les bugs de son propre programme avec les bugs impossible à corriger, et polluant un code qu'il faudra modifier de manière drastique.

Donc, je prône pour l'utilisation de ces "objets" avec parcimonie, et utiliser les éléments de base avec intelligence.

Pour en revenir avec le logiciel lui même, il serait intéressant de voir si la sortie texte de DcMoto peut gérer les fonctions graphiques de l'imprimante émulée…
Certains émulateurs utilisent des polices de caractère et non par génération de points, ce qui correspond à imprimer un fichier texte… et non à une émulation rigoureuse du therme.

J'ai soumis une matrice de la GP100a à l'auteur, pour voir si le rendu peut varier avec le type de machine.

[Falkor]

Les librairies open source Qt permettent de générer du PDF, en 64 bits, selon différentes méthodes...

https://wiki.qt.io/Handling_PDF

J'ai souvent utilisé ça sans soucis

[Daniel]

DCMOTO n'émule pas l'imprimante, il se contente d'écrire dans le fichier dcmoto-printer.txt tous les caractères envoyés à l'imprimante, sans distinction entre les caractères alphanumériques et les caractères de contrôle. En décodant ce fichier on doit pouvoir reconstituer l'impression exacte de l'imprimante réelle.

Je crois que plusieurs imprimantes Thomson ont été émulées par Préhisto dans l'émulateur TEO. C'est lui le meilleur spécialiste.

[gilles]

Effectivement prehisto a passé pas mal de temps sur l'émulation au pixel près des imprimantes thomson avec sortie vers fichier image (.png)
Exemple ici un fichier de fonte:
https://sourceforge.net/p/teoemulator/c ... /picas.txt

[Xavier_AL]

salut,

Merci pour ces infos!

à l'image de l'imprimante PR90-055, la LX80 utilise une police en pas de demi-pixels.
Et le logiciel "PrinterToPDF" utilise une matrice de 8bits de large maxi.
Pour la PR90-055, on a 12 bits de données en largeur!
Donc, on doit passer en 16bit...

Pour la hauteur, cela ne pose pas de problème car il suffit d'ajouter une line de 8 ou 16 bits.
Mais, pour le moment, le système est calibré sur du 8bits en datas horizontales. (8 points max)

Avant de découvrir ce logiciel, j'étais partie sur des datas en vertical, ce qui serai plus logique, car les caractères sont imprimés colonnes par colonnes! … et non ligne par ligne…

Le but sera de créer des fichiers de configuration à géométrie variable 5 point en horizontal / 7 en vertical… par exemple.

Le fichier texte de Préhisto, me semble un bon compromis pour conserver les données d'impression en fichier "ini".
Car pour le moment, une seule imprimante est émulée (une Siemens) compatible Epson.

Il faudra donc exporter un bon nombre de variables: matrice de points, décalage horizontal, vertical et caractères de contrôle car pas forcément compatible ESC d'Epson.

Après de nombreuses tentatives pour compiler le programme, il apparait que le C utilisé est moins "capricieux" que les compilateurs en mingw32.
Sous TDM-GCC 4.9.2 w32

Exemple:

Code : Tout sélectionner

       case 1:
            // MSB is set byte 7 to 0
            xd = (int) xd & 127;
            break;

533 27 D:\backup_E\xav\PrinterToPDF-master\PrinterConvert.c [Error] invalid conversion from 'int' to 'char*' [-fpermissive]

Il faudra donc spécifier les adaptations de compatibilités de définitions… alors que le compilateur Linux, lui, semble avaler tout sans broncher!
Et cela rend effectivement pénible le codage, et je rejoins Gilles ("je préfère rester sous linux") pour des codes sources non optimisés pour windows.

Je regarde ce que je peux faire, mais reconstruire le programme sous une autre plateforme serait plus simple et moins chronophage... voir plus amusant.
En même temps, le mode console n'est pas trop glamour, et peu pratique.

[hlide]

Ce n'est pas lié à une différence entre Windows et Linux mais à une différence de version entre gcc, et du paramètrage par défaut du CFLAGS. Plus les versions de gcc augmentent, plus les nouvelles normes sont appliquées - ce ne sont pas des caprices mais la paresse de codeurs qui ne prennent pas la peine d'expliciter clairement qui font ressortir ces warnings.

La réponse est -fpermissive (à ajouter dans le CFLAGS) pour faire disparaître ce genre de warning.

[gilles]

c'est une question de gcc trop vieux dans dev-c++, c'est dommage parceque c'était un bon outil mais il en existe d'autres qui existent sur linux et windows. Code::blocks par exemple, netbeans aussi. voire même eclipse qui tourne bien avec des machines modernes.
Casser régulièrement sa machine de dev (volontairement) et travailler à plusieurs sur le même projet (idéalement avec un IDE différent) permet de toujours pouvoir repartir de 0.

par contre je ne suis pas d'accord sur la "paresse" supposée des codeurs, perso je trouve que ça devrait rester du warning et continuer de compiler. c'est pénible de reprendre du code correct qui a 20 ans parcequ'un extrémiste a décidé qu'il fallait utiliser "const" tout le temps. Améliorer oui, casser l'ancien non parce-que généralement on fait ça trop vite et on fait des dégâts pour compiler coûte que coûte.

[Xavier_AL]

je l'ai mis dans le make file, mais il semble ne pas aimer … le reste.

Code : Tout sélectionner

BIN      = PrinterToPDF.exe
CXXFLAGS = $(CXXINCS) -traditional-cpp -m32 -fpermissive
CFLAGS   = $(INCS) -traditional-cpp -m32 -Dmain=SDL_main -DWin32=TRUE -fpermissive
RM       = rm.exe -f

apparemment, une librairie passe mal…


Oui, Gilles, on se retrouve avec des incompatibilités "structurelles" et non fonctionnelle.
Bilan, non seulement on doit coder, mais en plus, on doit faire le boulot de l'interpréteur/compilateur.

[__sam__]

De toute façon développer en C est devenu une vraie gageure.

En ce moment je me bats avec amiga-gcc pour le compiler avec PortableMSYS2. C'est supposé marcher lentement (>20h de compile sous windows vs 10mins sous linux: pourquoi?????) mais marcher quand même, mais en fait et ca déconne pour pleins de raisons incompréhensibles (chemins dans les fichiers, fichiers pas bien copiés, etc etc). Mon interprétation est que dorénavant on ne sait *PLUS* faire de code portable à cause du trop gros nombre de dépendances explicites ou ... implicites (il y a même des dépendances implicites sur la version du shell qu'on utilise, ou la version du make ou autre outil tiers... pfff). Il y a sans arrêt des soucis de bibliothèques et de cochonneries systèmes parfaitement dispensables, si bien qu'en réalité beaucoup des projets soit-disant portables sous github ne marchent dans les faits que sur la machine du développeur. Si on veut recompiler soi-même, on est bon pour installer une VM avec exactement le même setup.

Aussi, pour les trucs rapides je ne fais plus que du LUA et c'est marre. Au moins ca marche partout et ca convient très bien pour ce que je fais. Quand ca tourne sous graphx2, c'est à dire avec des primitives graphiques, je me sens comme devant les basics des ordis 8 bits et c'est un vrai bonheur à pratiquer. Perso j'aurais même fichtrement envie d'avoir du LUA pour ordis 8bits en remplacement du basic... mais c'est une autre histoire.

[hlide]

par contre je ne suis pas d'accord sur la "paresse" supposée des codeurs, perso je trouve que ça devrait rester du warning et continuer de compiler.

Ok, j'ai été un peu fort sur "paresse". La ligne est claire, il faut ajouter "-fpermissive" pour ne pas en être dérangé.
En ce qui me concerne, je trouve cette ligne `xd = (int) xd & 127;` incompréhensible : c'est quoi xd ? un pointeur `char*` que l'on convertit en `int`? euh, c'est quoi cette manipulation ? vous trouvez ça clair ? maintenant si je vous dis que `int` est 32-bit et `char*` un pointeur 64-bit. Eh bien, le compilateur a parfaitement raison de râler car je ne vous dis pas les effets de bords dus à ce genre d'astuce quand on m'a demandé de porter du source 32-bit en 64-bit. C'est tout simplement du code NON-PORTABLE, parce qu'un "paresseux" a cru bon de faire de l'arithmétique avec un pointeur IMPLICITEMENT sans dire au compilateur que c'est bien l'intention recherchée. Et quand ce doit être un autre codeur ou le même 2 ans après qui doit faire un portage vers du 64-bit, il ne voit pas immédiatement un problème. Ceci dit, je me demande si l'erreur remontée concerne bien cette ligne parce que je ne comprend pas l'intérêt de cette ligne si `xd` est réellement un pointeur.

[hlide]

en réalité beaucoup des projets soit-disant portables sous github ne marchent dans les faits que sur la machine du développeur. Si on veut recompiler soi-même, on est bon pour installer une VM avec exactement le même setup.

C'est clair, il n'est pas rare de se trouver dans ce cas là parce qu'en publiant les sources, il n'y a pas eu ce travail pour s'assurer un environnement clairement défini et publiquement disponible. On les repère assez vite.

[Xavier_AL]

Et c'est la cas pour de nombreux languages… et Visual Basic n'est pas en reste!
Je prend le cas d'un programme tournant sur un OCX exotique, Excel par exemple.

Le programme va tourner chez le codeur qui a installé la solution Excel, mais, la diffusion des sources ne pourra pas être un gage de possibilité de reconstruction… car pour des problèmes de licences d'utilisation… l'OCX sera bloquée.

Résultat, il faut installer un programme dont ont à rien à faire, pour faire fonctionner une source qui ne fonctionnera pas.

Dans le cas qui nous préoccupe, non seulement il faut compiler le programme, mais aussi les DLL dédiées… non fournies dans les PACKs de librairies.
Donc, la SDL.DLL, la LibHPDF.dll, l'imageMagick… que l'on peut trouver sur le net, mais cela multiplie les risques d'incompatibilité de versions.
En fait, c'est un boulot de dingue, car installation des librairies avec tests, création des DLLs et une fois certain que rien ne pose problème … modifier les incompatibilités déclaratives…

Déjà 6 heures … pour préparer le compilateur… et il n'est pas certain que les versions soit sémantiquement compatibles.
Oui, les "Legos" sont formidables, mais une fois 5 boites mélangées, c'est la foire aux slips pour reconstituer les jolies création que l'on voie sur les boîtes et les livrets de construction.

Je suis d'accord pour dire qu'un environnement de compilation est unique et difficilement reproductibles sans faire un backup de plusieurs gigas.
Rien que les versions, mises à jours, priorité des paths, copies des fichiers "h" des includes trouvés sur le net… rendent unique le compilateur.

Je me rappelle d'un fil de discussion sur le partage des sources… avec un "Pourquoi tu ne partages pas tes sources ?"...
Au bout d'un moment, un programme "simple" devient une "pieuvre" qui ne peut plus quitter sa machine.

Partager un code, c'est donner une vue d'ensemble d'un travail effectué… mais, cela ne garantie en rien la possibilité de recompilation !
Pour les problèmes décrits précédemment… et certains semblent ne pas le comprendre.


Je continue à chercher… car je ne comprends pas pourquoi ça ne marche pas !