HomeProductsDownloadOrderSupportSearch
  
 
 Myriad Blog 1.3.0 Friday, Mar 29th, 2024 at 00:50am 

Tuesday, May 17th, 2011 at 04:58pm
Acam III étape 23

Depuis le début du portage sur Linux, nous craignons deux choses dans le domaine technique :  
1- que le système de développement fasse apparaître des lacunes nous empêchant de travailler confortablement, et  
2- que le système lui-même ne propose pas toutes les fonctionnalités dont nous avons besoin pour ce portage.

1- L'environnement de développement

 
Nous avons créé nos projets à l'aide d'une interface de développement (IDE) qui semblait, sur le papier, répondre à nos attentes : Code:Blocks.
Après quelque temps d'utilisation, il s'avère que ce produit semble assez limité. Des problèmes gênants d'édition et d'organisation se sont posés:
- impossibilité d'organiser les fichiers sources à sa guise dans des répertoires virtuels
- problèmes de reconnaissance de nos types C, ne permettant pas de retrouver facilement la définition de ces types dans nos fichiers sources
 
Ensuite, le débogueur pose de gros problèmes:
- Impossible d'arrêter le programme si on n'a pas posé un point d'arrêt avant
- visualisation des variables très ... variable, avec des oublis de certaines d'entre elles, impossibilité d'explorer le contenu de certains types, etc
- Impossible de quitter proprement une session de débogage, ce qui nous oblige à faire des "kill" à tour de bras dans un terminal pour s'en sortir
 
Nous avons donc essayé plusieurs autres environnements, qui se sont avérés encore plus problématiques. Sans entrer dans le détail :
 
- Codelite: prometteur mais ergonomie parfois étrange (par exemple, n'accepte pas les espaces dans les noms de dossiers), et ne semble pas apporter grand-chose de plus
 
- KDevelop: nous n'avons pas réussi à construire un projet GTK+ complet et fonctionnel. On y travaille, sans grand espoir.
 
- NetBeans: lourd et lent, ne contenant pas les outils de développement en C par défaut
 
- Anjuta: prometteur également, mais la prise en main est déroutante, nous n'avons même pas réussi à compiler un fichier source (ou alors, nous l'avons fait mais ne nous en sommes pas aperçus)
 
- Eclipse: un seul mot: lourd. Le démarrer est déjà une épreuve, le configurer pour compiler quelques-uns de nos sources C, n'en parlons même pas.
 
Nous sommes donc revenus à Code:Blocks, faisant fi des conseils avisés sur Internet expliquant qu'un environnement graphique est inutile, puisqu'il y a vim, gcc et gdb (80's revival rules!)
 
 
2- Les limites du système
 
Un exemple: Acam a besoin de connaître à tout moment les positions exactes de ses fenêtres sur l'écran, et doit pouvoir positionner une fenêtre où il le veut.  
 
Or, sur Linux, les deux opérations ne sont pas réflexives ! On peut ouvrir une fenêtre à un endroit donné, mais si on lit sa position juste après, on obtient (0,0), c'est-à-dire le coin supérieur gauche de l'écran. Il faut attendre un certain temps (définition, SVP) avant de la relire. Et là, la documentation est on ne peut plus claire. La position retournée est une approximation, il n'est pas possible de la connaître avec certitude. Il est d'ailleurs fortement déconseillé à une application de sauvegarder ces positions pour réouvrir les fenêtres au même endroit au prochain lancement !
 
Ceci est probablement lié aux communications entre les diverses couches logicielles gérant les fenêtres. Mais pour nous, cela devient un problème majeur. Nous y réfléchissons depuis plus d'une journée, mais n'avons pas encore découvert de solution absolue pour contourner cette incongruité.
by Olivier Guillion
Comments

Comment from Sylvain Machefert Tuesday, May 17th, 2011 at 07:23pm
Eclipse
Je ne connais pas le compilo C dans Eclipse, sûrement un truc à ajouter.
Mais si le C est à la hauteur du Java, du PHP ou d'Android, je ça promet.
En Java, y'a exécution OU débugage, l'exec ne va pas s'arrêter, le debug réagit bien aux points d'arrêts.
Inspection/Modification des variables impec
 
Je développe là-dessus en Java, PHP sur un gros projet, Android pour des tests (là c'est lourd car faut lancer en plus l'émulateur Android = 5 minutes...)
 
Lent sur mon AMD 2.4GHz chargé à la gueule et qui a 8 ans. Sur mon biproc au boulot, ça va plus vite.
 
Je ne connais pas les autres que tu cites.

Comment from Jean-Armand Tuesday, May 17th, 2011 at 11:05pm
Eclipse encore
Eclipse, lourd ? Oui, mais tout le monde l'utilise, au point que je n'ai jamais vu un autre IDE utilisé (à part NetBeans entraperçu de loin dans le brouillard juste une fois). En dehors de Visual Studio, bien sûr, qui est mieux pensé il faut reconnaître.
 
Mais Eclipse, c'est un environnement graphique qui sert à bâtir des outils qui font n'importe quoi, pas seulement du développement. C'est peut-être là qu'est le problème : trop riche.


Most recent first
Oldest first

Top of page
Legal information Cookies Last update:  (c) Myriad