Journal Un environnement de dev dans son téléphone.

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
33
26
août
2024

Sommaire

Bonjour 'nal :)

J'étais tranquille en train de me promener dans le store F-Droid quand TermuC (GitHub) a traversé mon écran. Son descriptif m'interpelle :

TermuC is a simple C/C++ IDE backed on powerful Termux. Install Termux first and install clang in Termux to supply the compiler and language server.

« Ah tiens, marrant », me dis-je, « il y aurait moyen de développer directement sur le téléphone ? Je me demande comment ça se met ».

Je suis la doc, qui indique de commencer par installer Termux (GitHub) et d'ensuite installer Clang dans Termux. Go pour le descriptif de Termux :

Termux combines powerful terminal emulation with an extensive Linux package collection.

Attends, que…oi ?! Tu veux dire que je peux avoir un terminal avec un gestionnaire de paquets et tout et tout, directement sur mon téléphone ? Ah mais délire. J'installe.

Un environnement de dev avec Termux.

Termux s'installe facilement et ne demande que des autorisation très basiques. Si tu n'utilises pas F-Droid tu peux aussi le retrouver dans le Play Store. TermuC communique avec Termux via le système d'Intent d'Android qui nécessite une autorisation supplémentaire.

Perso ce besoin m'a un peu refroidi même s'il n'y a pas vraiment de raison. Ajoute à cela que je n'ai pas apprécié d'IDE depuis le siècle dernier et tu comprendras que je me suis contenté du terminal de Termux. Chez moi ça se présente comme ceci :

Sans surprise, c'est effectivement un terminal. Le clavier est augmenté d'une série de touches bien pratiques : modificateurs, navigation, slash et tiret.

Il semblerait que le système soit basé sur Debian puisqu'on peu y utiliser apt pour installer les paquets. Les dépôts sont ceux de Termux, indépendants de Debian. Très bien, allez hop : apt install clang cmake emacs git ninja. Et voilà, ça fonctionne déjà.

Quelques pièges

Alors ça fonctionne, ça fonctionne… Oui, mais ce n'est pas si simple. J'ai récupéré Bim!, le jeu que je développe, et tenté de le compiler. Je me suis pris une petite leçon de portabilité du code !

__ANDROID__ n'est pas ce que tu crois.

Habituellement, et il me semble que c'est une pratique reconnue, j'utilise la définition du préprocesseur C __ANDROID__ pour savoir si je suis en train de compiler du code natif pour une l'application Android. J'insiste que ce qui m'intéresse est de savoir que c'est une application au sens Play Store.

Or, lors d'une compilation dans l'environnement Termux, __ANDROID__ est bien défini. Cela fait tout à fait sens, mais ça surprend. En effet, quand j'ai des bouts de code qui font des appels JNI, ça n'a aucun intérêt de les activer dans le terminal. J'ai donc dû abandonner cette définition du préprocesseur et passer l'info explicitement, par exemple en détectant la variable CMake CMAKE_ANDROID_NDK qui est définie par la toolchain Android lors de l'utilisation du NDK. À partir de là je peux définir une macro pour activer ou désactiver le code destiné à l'application Android.

/tmp n'existe pas.

On finit par oublier à l'usage mais il n'y a pas d'obligation à avoir un dossier /tmp sous Linux, et la bonne façon de récupérer le répertoire temporaire est d'utiliser la variable d'environnement TMPDIR. Après une mise à jour de GoogleTest et d'un petit projet à moi, plus de problème sur ce point. Enfin presque. Il semblerait que cette variable d'environnement ne soit pas définie dans l'image Docker Ubuntu 24.04, ce qui a donné des surprises sur la CI. Bon ben dans ce cas je repasse sur /tmp en secours, tant pis.

D'ailleurs, d'une manière générale, on ne peut pas compter sur l'arborescence traditionnelle pour les fichiers dans Termux. Tout est stocké dans /data/data/com.termux/files/, ce qui fait que les chemins classiques ne vont pas coller. Il est intéressant néanmoins de voir que le système va gérer correctement le shebang des scripts pour pointer vers l'interpréteur situé dans cette arborescence.

Au passage, une friture sympa proposée par l'app est d'« ouvrir » les fichiers téléchargés pour en fait les copier dans ~/downloads. J'ai cru que j'allais souffrir pour importer un zip téléchargé via Firefox et en fait ça s'est fait en deux-trois clics touchers.

La lib C n'est pas GNU lib C

La lib C utilisée par Termux est celle du système, soit Bionic, la lib C d'Android. Dans les grandes lignes ça ne change pas grand chose, dans le détail ça donne quelques surprises. Pour moi ça a coincé sur l'absence du fichier monetary.h, mais en fait je n'en avait pas vraiment besoin. C'était un prérequis pour Boost.Locale qui elle-même était tirée par une autre dépendance, iscool::core. En découpant cette dernière afin de rendre ses parties désactivables, j'ai pu me libérer de Boost.Locale. Tant mieux, ça me fera moins de trucs à compiler.

Il n'y a pas des masses de ressources

Il y a huit cœurs sur mon téléphone, mais seulement 3.5 Go de RAM. En général ça va, mais quand on lance un ninja qui va exécuter en parallèle plein de jobs gourmands en mémoire, ça se passe mal. C'est assez flippant de lancer une compilation, partir visiter un site dans Firefox et voir le téléphone se bloquer. Pour contourner le problème, il n'y a pas de mystère, il faut lancer moins de jobs. Dommage que le parallélisme de Ninja ne puisse être contrôlé par une variable d'environnement, ça éviterait de le faire au cas par cas.

Éventuellement, si le build est fait via cmake --build, il y aurait la variable d'environnement CMAKE_BUILD_PARALLEL_LEVEL qui devrait faire l'affaire.

À l'usage

Au final on arrive à programmer directement sur le téléphone mais ça dépend pas mal de la tache à effectuer. J'ai pu écrire une série de tests, pour une centaine de lignes, et même quelques ajustements à gauche à droite. Faire un script Bash pour remplacer les commentaires de licences et mettre la ligne SPDX dans tous les fichiers sources, pareil, ça se fait bien.

Par contre quand j'ai tenté une refacto du code du matchmaking (le regroupement des demandes de parties de la part des joueurs afin qu'ils puissent jouer ensemble), c'était galère. Pour le coup je me suis senti bien à l'étroit dans les 56 colonnes et 29 lignes du terminal. Moi qui code habituellement avec deux fichiers côte à côte à l'écran, là c'était dur. Et je n'espérais même pas pouvoir tester le code en local ; il aurait fallu pouvoir lancer un serveur et au moins deux clients… Bref, ce n'est sans doute pas le meilleur environnement pour coder une application client-serveur.

Autre élément impossible à tester : quand la CI a sorti une erreur de compilation avec G++ en activant AddressSanitizer. J'ai été incapable d'utiliser ce dernier sur le téléphone, quant à installer G++ je n'ai même pas essayé !

Conclusion, oui c'est sympa mais seulement pour des bricoles. Et Termux est un beau projet :)

  • # ressources

    Posté par  (Mastodon) . Évalué à 8 (+5/-0). Dernière modification le 26 août 2024 à 23:17.

    Depuis quand 3.5GB ce n'est pas beaucoup?

    Sinon tu peux utiliser termux en local mais ne compiler que sur une machine distante…

    Tu ne l'as pas mentionné mais on peut faire tourner xorg et un bureau complet sous termux, et s'y connecter depuis un client vnc pour android.

    Si ton smartphone supporte l'utilisation d'écran externe via une docking usb-c ça te permet d'avoir un bureau linux portable.

    • [^] # Re: ressources

      Posté par  . Évalué à 7 (+5/-0).

      Depuis quand 3.5GB ce n'est pas beaucoup?

      Tout est horriblement gourmand malheureusement.

      Et Android n'hésite pas à dégager les processus qui tournent dans Termux, l'OOM killer marche d'enfer. C'est un modèle qui fonctionne bien avec les applications Android qui ne sont pas en premier plan, mais quand on utilise un environnement graphique dans Termux avec VNC, ça peut mal se passer, parce qu'Android ne considère pas tes processus Termux comme étant au premier plan dans cette situation malheureusement. C'est un truc que j'observais bien en 2019 avec un téléphone avec 4G de RAM. D'un coup, startkde se fait péter la gueule et paf la session (de mémoire).

      C'est pénible. Et en même temps ça reste un téléphone, s'il n'y a plus de mémoire pour gérer le SMS ou l'appel entrant ou la télémétrie à envoyer à Google parce que tu compiles un truc depuis ta session KDE, c'est un peu ballot.

  • # et l'inverse?

    Posté par  (site web personnel) . Évalué à 7 (+4/-0).

    Je fais comment pour avoir un téléphone dans mon environnement de développement ?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Installation de Termux à partir de Google Play

    Posté par  (site web personnel) . Évalué à 5 (+3/-0).

    Il y a quelques réserves : https://wiki.termux.com/wiki/Termux_Google_Play

    Pour nous émanciper des géants du numérique : Zelbinium !

  • # clavier, borg

    Posté par  . Évalué à 10 (+9/-0).

    J'utilise termux, un peu …
    Pour le clavier Unexpected Keyboard est pas mal, aussi dispo sur F-Droid.

    Je me sers notamment de termux pour faire un backup de mon tel sur un serveur Borg. Plus d'infos là

    Merci pour le partage sur l'environnement de dev

  • # Clavier souple + screen mirroring

    Posté par  . Évalué à 2 (+0/-0).

    Je me demande à quel point un clavier souple + un screen mirroring sur un écran de taille décente peut rendre le smartphone utilisable pour du développement.

    • [^] # Re: Clavier souple + screen mirroring

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

      Le clavier FrogPad (qui s'utilise à une seule main et pourrait se porter en bracelet) n'est plus fabriqué, c'est bien dommage. Ce serait parfait pour cette utilisation.

      En enlevant le clavier affiché sur l'écran du smartphone, on doit déjà à peu près doubler l'espace disponible pour afficher des choses. Pour une utilisation simple (et si on a une bonne vue et qu'on peut mettre une police de caractères assez petite, et si on a un smartphone moderne avec un grand écran) il n'y a peut-être pas besoin d'un écran externe? Après tout, il n'y a pas si longtemps on avait que 640x480 pixels et on se débrouillait bien avec?

      • [^] # Re: Clavier souple + screen mirroring

        Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

        Le 640 x 480, c’était il y a longtemps. Par exemple, les jeux ont commencé à exiger une définition supérieure il y a 25 ans (Age of Empires II, sorti le 30 septembre 1999 demandait au minimum du 800 x 600).

        La connaissance libre : https://zestedesavoir.com

        • [^] # Re: Clavier souple + screen mirroring

          Posté par  (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 28 août 2024 à 12:12.

          Tu serais pas en train de nous traiter de vieux?

          D'origine un Amiga 500 c'était une résolution max de 640×512 en 16 couleurs et 320×256 en 64 couleurs. Un Atari 520ST avait une résolution maximum respective de 640 × 400, en monochrome et seulement 320 × 200 en 16 couleurs. Un Macintosh SE/30 c'était du 512x342 en monochrome sur un écran de 9 pouces.

      • [^] # Re: Clavier souple + screen mirroring

        Posté par  . Évalué à 2 (+0/-0).

        Après tout, il n'y a pas si longtemps on avait que 640x480 pixels et on se débrouillait bien avec?

        Les tailles d'écran n'étaient pas les même.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Clavier souple + screen mirroring

        Posté par  (Mastodon) . Évalué à 5 (+2/-0).

        Alors on n'avait des résolutions plus petites mais un écran aussi un peu plus gros. Avec une écran de 6-7 pouces de diagonale tu dois faire un compromis entre afficher beaucoup d'info à l'écran ou afficher moins mais de manière lisible?

        Mais oui c'est clairement possible de n'utiliser que l'écran d'origine, je l'ai testé récemment sur un smartphone qui fonctionne bien à part le touch screen qui se bloque de manière régulière. Au début je croyais que c'était le smartphone qui se figeait mais je me suis rendu compte qu'il répondait aux boutons physiques. J'ai branché un combo clavier+trackpad et miracle, oui il est utilisable! Pour l'instant le seul usage vaguement intéressant que j'ai trouvée de mon smartphone au touchscreen qui déconne, c'est de l'utiliser dans ma cuisine pour consulter des recettes et contrôler la musique quand je n'ai pas envie de salir mon smartphone ou laptop principal avec mes mains pleines de farines et de beurre.

        Donc du coup, plutôt que de prendre un laptop en voyage, avoir android + termux + un clavier sans-fil compact peut se concevoir si on a une "coque" de protection qui permet au smartphone de tenir debout tout seul. Par contre il faut avoir une table ou un support car sur les genous ce serait la galère là où un laptop est utilisable sur un fauteuil ou canapé. Comme appareil principal ça me semble limité et inconfortable vue la taille de l'écran. Je ne crois pas que ce soit compatible avec les recommendations ergonomiques de la médecine du travail.

        termux sur smartphone avec un clavier sans file connecté via dongle usb

        Alternative: utiliser des "smartglasses" type XReal Air ou un casque VR mais du coup pour ce dernier on retrouve la question de l'encombrement par rapport à un laptop.

  • # Termux , c'est mort sur Android 5 et 6

    Posté par  . Évalué à 3 (+1/-0). Dernière modification le 27 août 2024 à 17:58.

    https://github.com/termux/termux-app/wiki/Termux-on-android-5-or-6

    Quel dommage, je m'en étais déjà pas mal servi avec un autre telef. Bien pratique pour une session ssh.

    Je trouve plutôt fendard l'idée de programmer directement depuis le telef.
    Dire que j'étais motivé à enfin me mettre au langage C.
    Genre "Hello World" ;)

    "Si tous les cons volaient, il ferait nuit" F. Dard

    • [^] # Re: Termux , c'est mort sur Android 5 et 6

      Posté par  (Mastodon) . Évalué à 3 (+0/-0).

      Dire que j'étais motivé à enfin me mettre au langage C.

      Étant principalement programmeur C, j'avoue que je saurais pas trop guider qqu'un qui veut découvrir le C pour lui faire faire des trucs un minimum sympa et rapidement gratifiants. Je pense que je partirais plutôt vers la programmation d'un Arduino.

      Après t'es Linuxien, on doit pouvoir imaginer des programmes axés "système" à peu près utiles et pas trop lourds à implémenter.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Termux , c'est mort sur Android 5 et 6

        Posté par  (site web personnel, Mastodon) . Évalué à 1 (+0/-0).

        Genre un "grep", simple et visible. En CLI il y en a pas mal quand même. Faire de la GUI ça demande un peu plus. Après il y a des lib.

        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

      • [^] # Re: Termux , c'est mort sur Android 5 et 6

        Posté par  . Évalué à 3 (+1/-0).

        J'ai bien fait 2 3 bricolages à base d'Arduino Pro Micro (des périphériques MIDI) et d'ESP32 (pour piloter une pompe), mais au niveau programmation c'est plus du copié collé sauvage et l'utilisation des bibliothèques qui vont bien. Mais c'est vrai que c'est à peu près compréhensible.

        Par contre quand je regarde le code source dans le noyau Linux d'un pilote pour un chipset audio, avec la datasheet à portée de main, c'est quand même très obscur.

        "Si tous les cons volaient, il ferait nuit" F. Dard

        • [^] # Re: Termux , c'est mort sur Android 5 et 6

          Posté par  . Évalué à 2 (+0/-0).

          Le code noyau selon où tu tombe peut être assez particulier du fais que ce soit un noyau et un driver c'est un bout de code noyau. Si c'est ce que tu cherche continue, mais sinon tu peux regarder les binutils ou le code des projets suckless par exemple

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Termux , c'est mort sur Android 5 et 6

            Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

            Personellement, le code incompréhensible, j'en trouve dans Linux mais moins dans d'autres systèmes d'exploitation. Le fait cue ça soit du code noyau n'est pas une excuse pour l'absence de commentaires, les APIs mal documentées, l'absence de logs alors qu'un framework existe pour en faire.

            Je crois surtout que la lisibilité du code n'est pas un critère hrioritaire pour les développeurs de drivers (ils ont surtout envie que ça fonctionne sur le matériel sur lequel ils sont en train de travailler).

            L'excuse de "oui mais c'est du code noyau, les règles et bonnes pratiques de l'industrie ne s'appliquent pas" a un côté élitiste que je n'aime pas trop. Au contraire, c'est du code critique pour lequel il faudrait faire deux fois plus attention à ce qu'il soit clair et facile à suivre.

          • [^] # Re: Termux , c'est mort sur Android 5 et 6

            Posté par  . Évalué à 2 (+0/-0).

            Si c'est ce que tu cherche continue

            ah bah, c'est ce que je fais depuis plusieurs dizaines d'années (sans exagérer) pour comprendre comment ça marche la couche audio/Alsa du noyau.

            C'est pas franchement trivial, mais je pense avoir démêlé au moins le fonctionnement global (disons, du driver matériel à amixer).
            Toutefois, souvent, l'implémentation reste bien mystérieuse.

            Il faut dire, comme ici, que le code source mal/pas commenté n'aide pas à s'approprier les choses.

            "Si tous les cons volaient, il ferait nuit" F. Dard

      • [^] # Re: Termux , c'est mort sur Android 5 et 6

        Posté par  . Évalué à 3 (+1/-0).

        Arduino, c'est un truc chelou, entre du C et du C++, une espèce de chimère à base de C++ écrit en style C. Je ne suis pas sûr que ce soir le meilleur truc à filer à un débutant en C… Rien que lire le code des libs Arduino existantes est un coup à filer de très mauvais habitudes.

        Par contre, c'est génial pour mettre un pied dans la programmation embarquée sans plonger direct dans les datasheet, les configuration des bus et des pins, etc… Même si ST a fait un gros taf là dessus avec ST Cube pour ses STM32, ça reste un peu difficile à appréhender pour un débutant.

  • # alternative...

    Posté par  . Évalué à 4 (+3/-0).

    utiliser une vraie distro open source linux dans son appareil ;)

    https://fr.wikipedia.org/wiki/Liste_des_syst%C3%A8mes_mobiles_non_bas%C3%A9s_sur_Android

    (j'envoie volontairement des fleurs à postmarketos ;) )

  • # bonne variable d’environnement pour le dossier temporaire

    Posté par  . Évalué à 2 (+2/-0).

    Il semblerait que cette variable d'environnement ne soit pas définie dans l'image Docker Ubuntu 24.04, ce qui a donné des surprises sur la CI. Bon ben dans ce cas je repasse sur /tmp en secours, tant pis.
    Merci pour le (début de) tips, ça m'a justement servi pour un projet en court.

    J'avais le même problème d'absence de variable TMPDIR sous Fedora, et après une recherche, j'ai lu que la variable d'environnement à utiliser était plutôt XDG_RUNTIME_DIR pour moi en tout cas.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.