Bien sûr que c’est partagé (gdb). L’intérêt de cette méthode c’est justement de ne dédié à l’hôte (le pi) que les taches liées à son system propre en le déchargeant de tout le reste, y compris du lourd support d’un environnement de dev locale. Par défaut les sorties sont générées sur le pi, mais rien n’empêche de les rediriger ailleurs (idéalement sur la machine de dev). Finalement c’est le principe même de la philosophie linux. Soit tu utilises des programmes spécifiquement compilés pour ton system ou alors tu compiles toi-même les sources in-situ.spourre a écrit :J'ai survolé rapidement le lien que tu donnes et les captures d'écrans m'ont fait penser à une compilation répartie (voire entièrement sur le pi):
La cross-compilation intégrale, c’est (c'était) bien, mais effectivement ça n’a rien de trivial et jamais de garantie que tes compilations fonctionneront sur le system finale, surtout à la vitesse ou vont les changements de version soft et hard. Si au moins on pouvait s’appuyer sur des émulations parfaitement conformes et à jour, cela irait, mais c’est rarement le cas. En plus coté débogage c’est l’enfer des que l’on porte sur du spécifique. Pour moi, ces méthodes sont d’une même époque que le dev en cli. Autrefois, on n’avait pas le choix et il faut bien avouer que c’était une belle galère. Pour moi, avec les outils dispo aujourd’hui, utiliser ces vielles méthodes relève au mieux de la nostalgie et au pire du sadomasochisme. Ceci dit, j’ai aussi ce côté maso, je développe encore mes pic en assembleur avec nodepad. A moins que ce soit de la nostalgie, va savoir
Eclipse te permet aussi de faire du debug et de la cross-compil gdb et ca va plutôt pas mal (bien que je n'ai jamais essayé pour le pi)