Forum TI-Planet.org

Plop, (je vise en particulier Lionel Debroux)

Ma tâche auto-infligée du moment dans KnightOS étant d'implémenter la communication PC <> calculatrice via la liaison série (plus particulièrement le silverlink), j'ai besoin d'utiliser libticables. Le truc c'est que j'arrive vraiment pas à me débrouiller.

Avec d'autres libs genre la SDL, c'est facile, y'a qu'à inclure les fichiers .lib dans un projet VC++, donner les répertoires des .h et c'est bon. Là apparemment je dois compiler la lib depuis la source ... et franchement, entre Glade, GTK, Bison/Flex, MinGW etoo, j'ai vraiment pas la foi. Est-ce que des binaries ou dev files existent pour Windows, histoire que j'aie juste quelques paths à donner à VC++ pour que ça marche ? Je crois avoir trouvé pour Ubuntu, mais bon, c'est pour Ubuntu.

Ma tâche auto-infligée du moment dans KnightOS étant d'implémenter la communication PC <> calculatrice via la liaison série (plus particulièrement le silverlink)

Hu hu
C'est un bon choix d'utiliser libti*. Certes, même si libti* reste loin d'être parfaite à l'intérieur malgré tous les efforts, il n'y a de toute façon rien d'autre qui soit portable et suffisamment complet (gestion de tous les câbles et à peu près tous les modèles).
On pourrait vouloir redévelopper from scratch, mais je peux vous assurer que n'avez pas envie de vous faire chier - et de faire chier les utilisateurs, à cause de choix techniques volontaires de Windows qui s'aggravent au cours du temps - avec des drivers USB Windows

Commençons par des infos sur la (cross-)compilation de libti*:
* pour mettre en place la compilation Windows native avec MSVC, le composant le plus utile pour le build est un SDK Glade précompilé, du projet gladewin32, qui contient la plupart des dépendances chiantes et fonctionne bien, même si c'est une très vieille version. Il y a des fichiers projets MSVC dans le repository.
* je n'ai réalisé la compilation Windows avec MSVC que la toute première fois, pour TILP II 1.14 beta, avec MSVC 2008 Express à l'époque. Depuis, j'utilise exclusivement la compilation native et la cross-compilation depuis Linux, grâce aux scripts mainteneur recompile_* que j'ai committés à https://github.com/debrouxl/tilp_and_gf ... ld/scripts . recompile_cross_tilp.sh nécessite également du setup initial, forcément, mais après, il fonctionne très, très bien: tous les builds que j'ai produits depuis 2010 ont été faits avec. Le fait que les fichiers MSVC du repository soient inutilisés veut dire qu'ils ne sont pas à jour: il faut ajouter au moins libarchive, qui a remplacé le fork de minizip (...) auparavant intégré au repository.
* le script utilisateur install_tilp.sh dans le même répertoire est plus connu que les scripts mainteneur, son endroit habituel de téléchargement est http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh .

Ensuite, pour pouvoir utiliser libti* sous Windows sans le compiler:
* il est vrai que le système de build ne fournit pas de .lib permettant d'importer le DLL, et le système de packaging ne fournit ni .h ni .lib dans l'installeur - mais c'est aussi parce que jusqu'à présent, personne n'en avait besoin
* je sais qu'il est facile de créer ce dont tu as besoin à court terme (est-ce tout ce dont tu as besoin ?): des .lib permettant d'importer les DLLs libti*. Une requête "MinGW make import lib from DLL" (puisque c'est la cross-toolchain MinGW que je vais utiliser depuis Linux) m'a mené vers http://www.mingw.org/wiki/createimportlibraries et http://www.mingw.org/wiki/msvc_and_mingw_dlls , qui contiennent également des infos pous MSVC. Je regarderai aussi comment libusb-win32 fait, mais je suis à peu près sûr que ses libs d'import sont faites ainsi.

Aussi, quelle version de MSVC vas-tu utiliser ? Microsoft a très récemment donné la possibilité d'utiliser une Community Edition de MSVC 2013 pour travailler sur des projets open source.

Oui, c'est vraiment tout ce dont j'ai besoin: des .lib pour les imports et des .h pour les prototypes de fonctions.

J'utilise VS2013.

Résumé de ce qu'on a vu avec matref ce soir sur IRC:
* générer des defs n'était pas difficile (et pour le faire correctement, j'ai fait un patch en local au système de build, je le diffuserai plus tard);
* créer des libs d'import à partir des defs était également facile;
* faire compiler un programme avec ticables.h, et le linker avec le .lib, se fait raisonnablement à partir du moment où un SDK comprenant glib est installé;
* en revanche, pour exécuter le programme... on a eu droit à l'habituelle panoplie de complications de setup (installation manuelle du filter driver libusb-win32, puis utilisation de Zadig, tout ça pour pouvoir utiliser un driver dont on rappelle quand même qu'il se base sur un driver signé) et d'exécution (le programme doit être démarré en administrateur, sinon il n'a pas assez de privilèges... ben voyons...), se terminant même par la magnifique erreur, je cite:

Exception non gérée à 0x77EB8F05 (ntdll.dll) dans silverlinkTest.exe : 0xC000007B: %hs n’est pas conçu pour s’exécuter sous Windows ou il contient une erreur. Installez à nouveau le programme à l’aide du support d’installation d’origine, ou bien contactez votre administrateur système ou le fournisseur du logiciel pour obtenir du support. État de l’erreur : 0x."

Les libs d'import et le programme de test a été produit par MSVC, et s'il est vrai que les libs libti* ont été produites sous Linux par un cross-compilo MinGW, c'est le setup que j'ai utilisé pour 4 releases et quelques dizaines de builds beta, en plus de 4 ans et demi... donc il paraît exclu que les composants incriminés ne soient pas conçus pour s'exécuter sous Windows
Quelle éventuelle erreur ils peuvent bien contenir, ça, mystère.

Bon courage matref

Haha nan mais, c'est mort. Quelqu'un d'autre le fera.

Tant que ça ne crée pas encore un driver supplémentaire, et d'autant plus d'emmerdes pour les utilisateurs de TI-Connect et/ou TILP sous Windows, ça me va

Je sais que tu ne voulais pas installer TILP, mais pour autant... est-ce que ça résoudrait une partie de tes problèmes ?
Tu as de toute façon déjà été obligé d'installer le runtime GTK+, puis le filter driver libusb-win32, puis d'utiliser Zadig... donc si la raison était que tu ne voulais pas mettre en place les dépendances de TILP, tu as quand même dû le faire pour soit pouvoir compiler, soit espérer pouvoir lancer le programme
Installer TILP (de préférence le dernier build beta en date, voir le topic ici sur TI-Planet) permettrait d'installer les DLLs libti* à un endroit standard (Common files) où ton programme, et d'autres, peuvent les trouver, puisque l'installeur de TILP enregistre les DLLs dans le système.

Je pourrais modifier l'installeur de TILP pour donner la possibilité de ne pas installer TILP, mais installer seulement libti* et les drivers. Et puis faire un seul installeur pour TILP + GFM, aussi. Mais la nécessité d'installer le runtime GTK+, qui ne permet pas de choisir les composants installés (libti* ayant seulement besoin de glib, intl, et quelques autres dépendances), restera.