Comment aborder efficacement des projets Linux / makefile massifs?

Je développe des applications Windows en C ++ depuis environ 10 ans maintenant. Et récemment, j'ai commencé à creuser dans certains projets Linux, et je ne peux pas supporter à quel point je suis improductif ...

J'apprends vite et j'utilise Linux comme plate-forme principale depuis un certain temps maintenant. Et je me sens très à l'aise avec le shell, les principes du système d'exploitation et l'interface graphique. Mais quand il s'agit de développement, j'ai l'impression de retourner à l'école.

Dès que j'ouvre un projet plus important, je suis bloqué. La plupart d'entre eux sont basés sur un makefile, donc, fondamentalement, lorsque j'essaie de les parcourir avec QT ou CodeBlocks, au mieux, je peux utiliser intellisense fichier par fichier. Et la plupart des variables temporelles s'échappent de la portée.

Ensuite, il y a un élément de définition, qui semble inexistant, essayez de rejoindre un projet plus important de sourceforge, et vous êtes coincé pendant des jours, car la navigation vers les définitions est si difficile ... grep -r "this_def" . --include "*.cpp" --include "*.h"semble si lente et maladroite.

Et puis, le débogage, gdb fonctionne, mais peu importe ce que je fais, il semble que ce soit des années-lumière derrière le débogueur WinDbg ou VisualStudio.

Et ces choses me désespèrent, je veux écrire du code, mais ça va tellement lentement ... Je commence à penser que les développeurs Linux apprennent les définitions de fonctions par cœur et analysent le code par les yeux, mais je ne peux pas croire que ce soit donc.

Quelqu'un est-il passé par là? Y a-t-il quelque chose qui me manque qui pourrait me rendre plus productif?

Chose intéressante, j'ai périodiquement le même problème dans la direction opposée. Je suis principalement un codeur UNIX, mais je dois périodiquement porter des trucs sur Windows. Je ne peux pas vous dire combien de fois j'ai voulu m'arracher les cheveux parce que je ne trouve pas la case à cocher appropriée pour une option de compilation enfouie dans l'une des 35 pages de configuration des préférences pour un projet. Je préfère simplement ouvrir le fichier proj et ajouter le XML moi-même.

Dans les deux sens, le secret est d'avoir de la patience et d'apprendre l'ensemble d'outils pour la plate-forme dans laquelle vous essayez de travailler. Bien sûr, vous allez être frustré, c'est nouveau et c'est peu familier et vous êtes réduit au statut de débutant encore une fois. Il n'y a aucun moyen d'éviter cela.

Dans votre cas particulier, vous devez connaître certains outils supplémentaires. Le premier est DDD , une interface graphique pour gdb. Ce n'est pas aussi lisse que Visual Studio, mais il vous tiendra la main. Cependant, je recommanderais vraiment de mordre la balle et de commencer à apprendre les tenants et aboutissants de gdb. En vérité, si vous êtes un utilisateur régulier, il n'y a pas beaucoup de différence entre la mémorisation des commandes à taper et la mémorisation de la boîte de dialogue que vous devez afficher pour modifier un paramètre.

Vous devez également connaître des outils tels que CScope et CTags . Autant que vous puissiez résister, je suggère d'apprendre VIM ou EMACS . Ils s'intègrent bien avec les outils de tag que je viens de mentionner. A Rome, fais comme les Romains. Vous pouvez trouver des extensions pour VIM et EMACS qui feront la complétion de code pour vous. Ma propre expérience avec les outils qui offrent la complétion de code est que oui, cela permet d'économiser de la frappe, mais en général, la frappe est facile. Penser, c'est ce qui est difficile. Votre opinion peut différer, en particulier si vous souffrez du syndrome du canal carpien.

Quant à faire. Make est certes horrible, mais vous allez probablement devoir le sucer et l'apprendre.

Je développe des applications Windows en C ++ depuis environ 10 ans maintenant. Et récemment, j'ai commencé à creuser dans certains projets Linux, et je ne peux pas supporter à quel point je suis improductif ...

Y a-t-il quelque chose qui me manque qui pourrait me rendre plus productif?

Développer sous Windows, déployer sous Linux.

Cela comprend l'exécution de tests unitaires à la fois sur votre propre machine (Windows) et sur le serveur de génération (Linux).

Comme effet secondaire, vous apprendrez à écrire du code portable.

Un autre effet positif est que l'utilisation de différents compilateurs générera plus d'avertissements et attrapera ainsi plus de bogues.

MISE À JOUR : À tous les fans de Linux qui votent pour cette réponse: je ne dis pas que tout le monde devrait se développer sur Windows! Mais utiliser la plateforme que vous connaissez très bien est plus productif que de passer beaucoup de temps à apprendre une nouvelle plateforme.

Votre problème a été résolu à plusieurs reprises dans le monde Linux, cependant, contrairement aux outils Windows / Microsoft, il ne sera pas remis sur une plaque d'argent avec un accompagnement d'extras. Vous devrez peut-être faire un travail pour l'obtenir.

J'utilise un éditeur commercial (Visual Slick Edit, qui est considéré comme cher par ceux qui ne valorisent pas leur temps autant que moi) pour ce problème précis. Eclipse avec le plugin CDT est un moyen open source qui a de nombreux succès justifiables. (Pas bon pour moi car j'ai souvent besoin du support ADA)

Ce que je ne fais pas, c'est essayer de désosser les makefiles en une sorte de projet. J'utilise la construction de l'IDE dans les systèmes et j'ajoute / supprime manuellement des fichiers selon les besoins. Je suis sûr que je pourrais l'écrire, mais le temps n'en vaut probablement pas la peine. Pour cela, j'ai trouvé l'éclipse un peu moins utilisable que Slickedit (cela pourrait facilement (et probablement a) changé depuis la dernière fois que j'ai regardé)

Linux a une vaste gamme d'outils, les gars qui savent que vi me surpassent dans tous les aspects de l'édition, il a des recherches de références, etc., juste une courbe d'apprentissage abrupte. Je suis certain qu'Emacs peut tout faire aussi bien que je ne l'ai jamais utilisé.

Pour ce que cela vaut, sous Linux, vous avez de meilleurs systèmes de construction que le vieux GNU simple (qui va souvent avec l'horrible autoconf ), par exemple omake et bien d'autres ( cmake, scons...).

une suggestion concernant la façon dont il est fastidieux d'utiliser grep pour rechercher du code: configurez des alias bash dans votre fichier .bashrc. Alors, c'est juste une seule commande:

alias searchCode='find -iname \*.cpp | xargs grep $1'
alias searchCodeHeaders='find -iname \*.h | xargs grep $1'

il y a probablement de meilleures façons d'écrire la commande, mais l'idée est la même. Voulez-vous rechercher le code? écrire un alias appelé searchCode. N'oubliez pas que bien qu'ils soient fastidieux et compliqués, les outils Unix peuvent également être utilisés pour vous faciliter la vie.

Mon 2c en tant que quelqu'un qui a développé C ++ sur les deux plates-formes et les aime tous les deux.

1) Les Makefiles sont douloureux - le meilleur conseil que je puisse vous donner est d'essayer de passer à un autre système de construction, si possible.

2) Pour l'édition de code et la navigation, il existe des outils très utiles. Bien sûr, ils ne sont pas intégrés, mais peu importe quand il s'agit de faire avancer les choses. vim + ctags + grep vous y emmèneront. Bien sûr, il y a aussi des IDE, mais franchement, je n'ai pas aimé tout ce que j'ai essayé: Eclipse + CDT, KDevelop, Code :: Block. Vous pouvez cependant arriver à une conclusion différente.

3) Pour le débogage, respectez simplement la ligne de commande gdb. Bien sûr, il est tout à fait derrière Windbg en ce qui concerne les fonctionnalités, mais pour la plupart des utilisations, c'est très bien. Les frontaux graphiques (ddd, KDbg) étaient assez bogués la dernière fois que je les ai essayés, mais encore une fois, les choses ont peut-être changé :)

L'essentiel est - oui, vous devez mettre un peu d'effort d'apprentissage, mais après cela, vous serez aussi productif que vous le faites sous Windows.

À tous les autres bons conseils que vous avez déjà reçus, je voudrais ajouter quelques liens, respectivement vers ack et pss .

Ils sont destinés aux programmeurs qui doivent se soucier spécifiquement du code source, en essayant d'améliorer Grep.

Excellentes réponses. Ajoutant à eux,

Quand j'ai fait ce mouvement, l'erreur que j'ai faite était d'essayer de sauter dans le code sans donner la diligence requise au système de construction GNU, qui est revenu me mordre quand je voulais faire des changements de code. Passez les quelques jours nécessaires pour comprendre le fonctionnement de la suite d'outils AutoMake / AutoConf / Make, vous serez très rapide après cela.

Concernant les outils - Eclipse + CDT / GDB + DDD va en effet très loin.

Voici quelques conseils pour le faire fonctionner plus facilement:

1. Commencez depuis le début. Cela signifie que vous utiliserez d'abord le script bash comme remplacement de makefile, puis des makefiles simples une fois que vous aurez besoin de dépendances. Restez simple au début. Votre makefile n'a pas besoin de gérer 15 plates-formes Unix différentes - il suffit de le compiler avec les dépendances. (votre makefile initial va ressembler à: all: g ++ -o main main.cpp) (un exemple plus complexe peut être trouvé sur http://sivut.koti.soon.fi/~terop/Makefile - en partant de zéro , copiez simplement le fichier dans le projet, changez les noms de fichiers, le répertoire mkdir objs, changez les bibliothèques que vous voulez)
2. Oubliez l'IDE. Cela ne fera que vous ralentir. Apprenez à lire le code et à mémoriser la hiérarchie des fichiers de votre projet. Les outils de ligne de commande normaux comme 'cd dir' et 'emacs foo.cpp' doivent être si automatiques que vous ne pensez pas à taper deux fois.
3. Oubliez la coloration syntaxique et l'intellisense. Cela ne fonctionnera jamais de la même manière que dans Visual Studio, et les indices que cela donne ne feront que vous embrouiller car c'est différent de ce que vous aviez l'habitude de faire. Apprenez à ne pas compter sur eux.
4. Gdb est un bon débogueur. Vous obtiendrez une pile d'appels. N'essayez même pas de contourner le code, cela ne fonctionnera pas très bien. Utilisez également valgrind. Les points d'arrêt sont également bons, mais ne vous y fiez pas trop; rarement utilisé avec gdb.
5. Si votre compilation est autre chose qu'un simple «make» dans le shell, vous devez repenser votre cycle edit-compile-debug-edit -cycle.
6. Voici une astuce que Visual Studio ne peut pas faire: afficher à la fois le fichier d'en-tête et le fichier .cpp sur l'écran - afin que les deux soient visibles sans basculer entre eux avec des onglets. Emacs peut le faire. Le bloc-notes ne peut pas non plus. Visual studio ou IDE ne peuvent pas.
7. Apprenez les raccourcis clavier emacs. Ça va vous rendre plus rapide. Un bon indice est que toutes les touches sont situées très près du clavier. Les séquences de commandes sont plus longues, mais il est encore plus rapide de les taper.
8. Il existe une astuce simple pour remplacer go-to-definition: écrire le code dans le même fichier et utiliser esc- <et Cs :: myfunction dans emacs pour trouver la fonction souhaitée. Le processus est différent si vous avez utilisé de nombreux fichiers courts - votre code sera différent. (apprenez ctrl-f dans le bloc-notes, et vous aurez l'idée). Mais vous n'avez certainement pas besoin de le faire en shell.
9. Le temps de démarrage de l'éditeur de texte est très important. S'il faut plus d'une seconde pour l'ouvrir, ce n'est pas bon. Chaque IDE est cassé à cause de cette exigence. Le bloc-notes et les emacs sont ok.
10. goto-line dans emacs est une fonctionnalité importante pour la programmation. Liez-le à une clé. J'utilise Cx g