Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
Bonjour, Pour ma part je développe depuis quelques années un programme cross-plateforme (Windows/Linux) en client lourd : https://openpaper.work/ . C'est du Python+GTK. Python est un langage très plaisant à utiliser. Par contre, dès qu'on utilise des librairies qui ne sont pas pure-Python, le packaging devient vite très compliqué. L'utilisation des bindings Gobject-introspection pour accéder à GTK n'améliore pas la situation. Sous GNU/Linux, je distribue ça surtout sous forme de Flatpak[1][2]. Ça me permet notamment de faire du déploiement continu[3][4]. Ça pose juste des problèmes d'accès aux scanners (et quelques autres périphériques pour d'autres applis) :/. Je le distribue aussi sous forme de paquets pip[5]. Les paquets incluent une commande à lancer pour vérifier et installer les dépendances qui ne peuvent pas être prises en charge par pip (`paperwork-gtk chkdeps`). Mais c'est moins pratique pour les utilisateurs, et ce n'est donc plus la méthode recommandée. Avec le temps, de gentils mainteneurs de paquets ont fait des paquets pour diverses distributions. Ça reste de loin la méthode la plus simple pour les utilisateurs. Le défaut pour moi, c'est que je ne peux pas faire de déploiement continu. Sous Windows, j'avais étudié la possibilité de faire de la cross-compilation, mais je n'ai pas retenu cette solution finalement. J'ai buté sur les bindings GObject Introspection : Si j'ai bien compris, le programme qui les génère (g-ir-scanner) a besoin de tourner sur le même système que le systẽme cible. De façon générale, dès qu'on utilise des librairies natives, la cross-compilation risque de causer des problèmes. Il me semble que pour cross-compiler des programmes Windows, la seule solution est d'utiliser les librairies Wine (ne serait-ce que pour le linkage). Du coup, c'est difficile d'être certain que le résultat fonctionnera de façon fiable sur un vrai Windows. Le même problème se pose pour les tests automatiques : On peut les lancer avec Wine, mais il n'y a aucune garantie que le comportement sera exactement le même que sur un vrai Windows. Vu que j'utilise GTK, le plus simple que j'ai trouvé est d'utiliser une VM Windows et MSYS2[6]. Dans MSYS2, j'utilise cx-freeze[7] pour créer un exécutable Windows. Cx_freeze n'a pas l'air de gérer très bien les bindings GObject-Introspection, donc j'ai dû bricoler un peu pour que ça passe (ajout de dépendances manquées par Cx_freeze à la main)[8]. L'exécutable est accompagné de plein de fichiers de données. J'en fait donc un ZIP[9] et l'upload sur un object storage OVH. C'est l'installateur NSIS[10][11] qui va le télécharger et l'extraire à l'installation. Du coup il télécharge toujours la dernière version construite par CI/CD (donc on est presque sur du CI/CD complet de bout en bout). Pour être honnête, je regrette d'avoir fait le portage à Windows de mon application. Ça m'a pris énormément de temps (développement de Pyinsane puis Libinsane pour accéder aux scanners sous Windows, difficulté pour packager, bugs à la c*n, etc). Mais bon, le gros de la difficulté est passé, et des gens s'en servent maintenant ... En tout cas, je ne porterais pas mes prochaines applications à Windows. Concernant Go, il ne me semble pas que Go intègre de librairie de GUI par défaut. Ça m'étonnerait aussi fortement qu'il existe une librairie en pure-Go cross-plateforme. Ça veut dire qu'il faut des bindings coincoin sur Qt ou GTK. Ça sent les problèmes aussi tordus que ceux que j'ai eu avec Python. De plus, je ne suis pas certain que l'éco-système de librairies pour le desktop basé sur Go soit aussi développé que celui de Python. Pour les applications Javascript genre Électron, dans le cadre de mes développements, je fais une allergie sévère au Javascript et aux machins « web ». Je trouve le langage Javascript infect, et de mon point de vue, cette approche est une rustine sur un problème qui aurait déjà dû être réglé plus proprement il y a longtemps. De toute façon, avec ça, je n'aurais sûrement pas pu accéder aux scanners. Pour Flutter/Dart, je ne connais pas. Au final, pour faire des GUI cross-plateformes, je me dis que l'approche Java/Swing était peut-être la bonne. Cordialement, --- [1] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/master/doc/install.flatpak.markdown [2] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/master/flatpak/master.json [3] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/3c9f624ef35b118f456b97b6bc0c7d6d3ee51742/.gitlab-ci.yml#L71 [4] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/pipelines [5] https://pypi.org/project/paperwork/ [6] https://www.msys2.org/ [7] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/3c9f624ef35b118f456b97b6bc0c7d6d3ee51742/.gitlab-ci.yml#L147 [8] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/3c9f624ef35b118f456b97b6bc0c7d6d3ee51742/paperwork-gtk/Makefile#L39 [9] https://download.openpaper.work/windows/x86/paperwork-master-latest.zip
Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
Bonjour, Compiler un programme golang sous Linux avec une cible MS Windows est très simple... quand tu n'embarques pas de libs exotiques. Evidemment, il faut éviter que le programme utilise des spécificités de Linux, comme par exemple le fait d'envoyer ses logs à Syslog. Pour certaines libs externes, ca cross compile mais ca plante au lancement sur la nouvelle plateforme. Par exemple le driver SQLite sous Golang sur une plateforme Mac car le developpeur de ce connecteur n'a pas de quoi tester sur Mac. Je te conseille donc d'avoir un MS Windows pour tester le bon fonctionnement même si tout s'est bien passé à la compilation. Ceci étant dit, entre Linux et MS Windows, ca marche plutôt bien si on reste avec les libs tierces connues. Il n'y a que pour la partie boites à outils graphiques que je galère. Pour être tranquille, je passe maintenant par du web avec Javascript en front et Go en back. Golang embarque un backend web dans sa lib std, donc la crosscompil est "garantie" sur le backend web. Pour les frameworks web Golang, pour ceux qui se reposent sur net/http de la lib std, ils doivent aussi passer en cross compil. S'agissant des boîtes à outils pour faire des clients lourds : Gtk+Golang ca va sous Linux mais je n'ai pas réussi à le faire tourner sous MS Windows (en cross compil ou en natif). Qt+Go n'était pas assez mature à l'époque. Tk essayé non pas avec Golang mais avec Perl (et ppar pour la transformation en .exe).En conclusion, Go+web ca marche du tonnerre et tu peux compiler sous Linux pour MS Windows. En client lourd, je n'ai pas réussi à faire ce que tu demandes. Mais il y a plein de nouvelles libs qui sont apparues depuis mes derniers tests, qui remontent à 3 ans.Bonne fin de semaine Guillaume Message d'origine De : Olivier Date : 20/11/2020 09:00 (GMT+01:00) À : ML Debian User French Objet : Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux @Etienne:Gcab est effectivement intéressant à connaître.Merci beaucoup pour ce lien.Le ven. 20 nov. 2020 à 08:14, Étienne Mollier a écrit :Bonjour Olivier, Olivier, on 2020-11-19 16:11:32 +0100: > 2. Un point très important pour moi est, par contre, si c'est possible de > pouvoir empaqueter depuis Linux/Debian l'application Windows et son > installateur sans utiliser Windows. > (Plusieurs outils comme Kivy annonce la possibilité de développer pour > plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur la > même plateforme que la cible). Je ne suis absolument pas versé dans le domaine de la distribution de programmes pour Windows, mais en faisant une petite recherche dans les paquets de Debian Sid, je suis tombé sur "gcab". L'outil est mis à disposition via la collection des "msitools" : https://wiki.gnome.org/msitools | msitools plans to be a solution for packaging and deployment | of cross-compiled Windows applications. C'est un collection de programmes pour empaqueter et déployer des utilitaires cross-compilés à destination de Windows. J'ignore ce que ça vaut en pratique, mais à la description, ça me semblait correspondre à votre cahier des charges. Quant à tester l'installateur, je suppose que wine ferait l'affaire dans un premier temps. Mais à terme, je pense qu'il faudrait au moins faire un test sur une machine Windows native, juste pour s'assurer qu'une coquille n'est pas passée entre les mailles du filet. Bonne journée, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/3, please excuse my verbosity.
Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
@Etienne: Gcab est effectivement intéressant à connaître. Merci beaucoup pour ce lien. Le ven. 20 nov. 2020 à 08:14, Étienne Mollier a écrit : > Bonjour Olivier, > > Olivier, on 2020-11-19 16:11:32 +0100: > > 2. Un point très important pour moi est, par contre, si c'est possible de > > pouvoir empaqueter depuis Linux/Debian l'application Windows et son > > installateur sans utiliser Windows. > > (Plusieurs outils comme Kivy annonce la possibilité de développer pour > > plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur > la > > même plateforme que la cible). > > Je ne suis absolument pas versé dans le domaine de la > distribution de programmes pour Windows, mais en faisant une > petite recherche dans les paquets de Debian Sid, je suis tombé > sur "gcab". L'outil est mis à disposition via la collection des > "msitools" : > > https://wiki.gnome.org/msitools > > | msitools plans to be a solution for packaging and deployment > | of cross-compiled Windows applications. > > C'est un collection de programmes pour empaqueter et déployer > des utilitaires cross-compilés à destination de Windows. > J'ignore ce que ça vaut en pratique, mais à la description, ça > me semblait correspondre à votre cahier des charges. > > Quant à tester l'installateur, je suppose que wine ferait > l'affaire dans un premier temps. Mais à terme, je pense qu'il > faudrait au moins faire un test sur une machine Windows native, > juste pour s'assurer qu'une coquille n'est pas passée entre les > mailles du filet. > > Bonne journée, > -- > Étienne Mollier > Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > Sent from /dev/pts/3, please excuse my verbosity. >
Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
Olivier writes: > Je serai très curieux de recueillir ici des retours d'expérience sur le > développement sous Debian (Buster) d'applications natives Windows/Linux. > > 1. Par application native, j'entends une application graphique avec > quelques champs de saisie et quelques boutons. > L'homogénéité du style de l'application avec les autres n'a pas > d'importance pour mon cas. > Le fait de coder avec des technos Web (HTML, JS, CSS) ou classiques n'est > pas important non plus. Je pense que tu peux le faire sans trop de problemes avec Java, en utilisant la GUI Swing (ou JavaFX), et Maven. -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
@Basile: Merci pour tes réponses. La possibilité de cross-compiler est une fonction clairement mise en avant par le language Go (cf [4]). Il semble même possible de cibler MacOS sans posséder la moindre licence ou le moindre matériel Apple ! J'imagine que "le terrain a été juridiquement balayé". [4] https://www.digitalocean.com/community/tutorials/how-to-build-go-executables-for-multiple-platforms-on-ubuntu-16-04 Le jeu. 19 nov. 2020 à 16:58, Basile Starynkevitch a écrit : > > On 11/19/20 4:11 PM, Olivier wrote: > > Bonjour, > > Je serai très curieux de recueillir ici des retours d'expérience sur le > développement sous Debian (Buster) d'applications natives Windows/Linux. > > > Nota Bene:* je n'ai jamais de ma vie utilisé Windows!* (Mais Linux depuis > 1993, et Unix depuis 1985) > > > Ça doit être faisable, mais *ça peut prendre des semaines de travail*, et > il n'est pas certain que l'exécutable ainsi produit soit légalement > diffusable. Je suggère une approche WSL et la *consultation d'un avocat > spécialiste en licences logicielles*. > > > Des pistes possibles seraient > > > Lire avec attention http://www.fr.linuxfromscratch.org/ > > Compiler GNU binutils depuis son code source depuis > https://www.gnu.org/software/binutils/ > > Compiler GCC depuis son code source sur http://gcc.gnu.org/ > > Utiliser une bibliothèque serveur HTTP telle que > https://coralbits.com/static/onion/ > > Il se trouve que j'ai contribué aussi bien à GCC qu'à libonion. > > > > La question centrale, c'est combien de temps êtes vous prêt à dépenser, et > pourquoi (et pour vous, qui vous paie ce temps de travail, qui se compte en > semaines). > > > Il est possible que l'acquisition d'une licence Windows soit moins > onéreuse que tout le travail à faire pour l'éviter. > > > Cordialement > > > -- > Basile Starynkevitch > > (only mine opinions / les opinions sont miennes uniquement) > 92340 Bourg-la-Reine, France > web page: starynkevitch.net/Basile/ > >
Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
C. Sur Flutter/Dart, dans [2], on peut lire qu'il faut construire/empaqueter sur la même plateforme que la plateforme cible. D. J'ai découvert Guark (cf [3]). Ça a l'air particulièrement intéressant. [2] https://flutter.dev/desktop [3] https://github.com/guark/guark Le jeu. 19 nov. 2020 à 16:11, Olivier a écrit : > Bonjour, > > Je serai très curieux de recueillir ici des retours d'expérience sur le > développement sous Debian (Buster) d'applications natives Windows/Linux. > > 1. Par application native, j'entends une application graphique avec > quelques champs de saisie et quelques boutons. > L'homogénéité du style de l'application avec les autres n'a pas > d'importance pour mon cas. > Le fait de coder avec des technos Web (HTML, JS, CSS) ou classiques n'est > pas important non plus. > Si j'ai la possibilité, j'apprécierai de coder en Python. > > 2. Un point très important pour moi est, par contre, si c'est possible de > pouvoir empaqueter depuis Linux/Debian l'application Windows et son > installateur sans utiliser Windows. > (Plusieurs outils comme Kivy annonce la possibilité de développer pour > plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur la > même plateforme que la cible). > > A. Qu'en pensez-vous ? Avez-vous déjà expérimenté une telle chose ? > B. En surfant, j'ai lu que le langage Go (cf [1] annonce la possibilité > d'empaqueter sur Linux pour Windows. Qu'en penser ? > C. J'ai lu des infos sur Flutter/Dart ou Qt mais rien de précis sur > l'empaquetage. > > [1] https://golangr.com/gui/ > > Slts >
Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
Bonjour Olivier, Olivier, on 2020-11-19 16:11:32 +0100: > 2. Un point très important pour moi est, par contre, si c'est possible de > pouvoir empaqueter depuis Linux/Debian l'application Windows et son > installateur sans utiliser Windows. > (Plusieurs outils comme Kivy annonce la possibilité de développer pour > plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur la > même plateforme que la cible). Je ne suis absolument pas versé dans le domaine de la distribution de programmes pour Windows, mais en faisant une petite recherche dans les paquets de Debian Sid, je suis tombé sur "gcab". L'outil est mis à disposition via la collection des "msitools" : https://wiki.gnome.org/msitools | msitools plans to be a solution for packaging and deployment | of cross-compiled Windows applications. C'est un collection de programmes pour empaqueter et déployer des utilitaires cross-compilés à destination de Windows. J'ignore ce que ça vaut en pratique, mais à la description, ça me semblait correspondre à votre cahier des charges. Quant à tester l'installateur, je suppose que wine ferait l'affaire dans un premier temps. Mais à terme, je pense qu'il faudrait au moins faire un test sur une machine Windows native, juste pour s'assurer qu'une coquille n'est pas passée entre les mailles du filet. Bonne journée, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/3, please excuse my verbosity. signature.asc Description: PGP signature
Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
On 11/19/20 4:56 PM, Basile Starynkevitch wrote: On 11/19/20 4:11 PM, Olivier wrote: Bonjour, Je serai très curieux de recueillir ici des retours d'expérience sur le développement sous Debian (Buster) d'applications natives Windows/Linux. Nota Bene:*je n'ai jamais de ma vie utilisé Windows!* (Mais Linux depuis 1993, et Unix depuis 1985) Ça doit être faisable, mais *ça peut prendre des semaines de travail*, et il n'est pas certain que l'exécutable ainsi produit soit légalement diffusable. Je suggère une approche WSL et la *consultation d'un avocat spécialiste en licences logicielles*. Des pistes possibles seraient Lire avec attention http://www.fr.linuxfromscratch.org/ Compiler GNU binutils depuis son code source depuis https://www.gnu.org/software/binutils/ Compiler GCC depuis son code source sur http://gcc.gnu.org/ Utiliser une bibliothèque serveur HTTP telle que https://coralbits.com/static/onion/ Il se trouve que j'ai contribué aussi bien à GCC qu'à libonion. J'ai oublié de préciser que GCC et binutils sont compilables puis utilisables comme compilateur croisé (/cross-compiler/). Le dévelopement d'application Windows sous Debian est possible. Une alternative est bien sûr de livrer un fichier bytecode compilé avec Ocaml. Voir http://ocaml.org/ pour les détails. Les fichiers bytecode Ocaml sont portables entre Windows et Linux, moyennant un certain nombre de précautions. (Il se trouve que j'ai marginalement contribué à Ocaml) Librement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
On 11/19/20 4:11 PM, Olivier wrote: Bonjour, Je serai très curieux de recueillir ici des retours d'expérience sur le développement sous Debian (Buster) d'applications natives Windows/Linux. Nota Bene:*je n'ai jamais de ma vie utilisé Windows!* (Mais Linux depuis 1993, et Unix depuis 1985) Ça doit être faisable, mais *ça peut prendre des semaines de travail*, et il n'est pas certain que l'exécutable ainsi produit soit légalement diffusable. Je suggère une approche WSL et la *consultation d'un avocat spécialiste en licences logicielles*. Des pistes possibles seraient Lire avec attention http://www.fr.linuxfromscratch.org/ Compiler GNU binutils depuis son code source depuis https://www.gnu.org/software/binutils/ Compiler GCC depuis son code source sur http://gcc.gnu.org/ Utiliser une bibliothèque serveur HTTP telle que https://coralbits.com/static/onion/ Il se trouve que j'ai contribué aussi bien à GCC qu'à libonion. La question centrale, c'est combien de temps êtes vous prêt à dépenser, et pourquoi (et pour vous, qui vous paie ce temps de travail, qui se compte en semaines). Il est possible que l'acquisition d'une licence Windows soit moins onéreuse que tout le travail à faire pour l'éviter. Cordialement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Conseils pour le développement sur Debian d'applications natives Windows/Linux
Bonjour, Je serai très curieux de recueillir ici des retours d'expérience sur le développement sous Debian (Buster) d'applications natives Windows/Linux. 1. Par application native, j'entends une application graphique avec quelques champs de saisie et quelques boutons. L'homogénéité du style de l'application avec les autres n'a pas d'importance pour mon cas. Le fait de coder avec des technos Web (HTML, JS, CSS) ou classiques n'est pas important non plus. Si j'ai la possibilité, j'apprécierai de coder en Python. 2. Un point très important pour moi est, par contre, si c'est possible de pouvoir empaqueter depuis Linux/Debian l'application Windows et son installateur sans utiliser Windows. (Plusieurs outils comme Kivy annonce la possibilité de développer pour plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur la même plateforme que la cible). A. Qu'en pensez-vous ? Avez-vous déjà expérimenté une telle chose ? B. En surfant, j'ai lu que le langage Go (cf [1] annonce la possibilité d'empaqueter sur Linux pour Windows. Qu'en penser ? C. J'ai lu des infos sur Flutter/Dart ou Qt mais rien de précis sur l'empaquetage. [1] https://golangr.com/gui/ Slts