Come affrontare efficacemente progetti di Linux / makefile di massa?

È interessante notare che periodicamente ho lo stesso problema nella direzione opposta. Sono principalmente un codificatore UNIX, ma periodicamente devo effettuare il routing su Windows. Non posso dirvi quante volte ho voluto strapparmi i capelli perché non riesco a trovare la casella di controllo appropriata per un'opzione del compilatore sepolta in una delle 35 pagine di impostazione delle preferenze per un progetto. Preferirei semplicemente aprire il file proj e aggiungere l'XML da solo.

Spostandoti in entrambe le direzioni, il segreto è avere pazienza e imparare il set di strumenti per la piattaforma in cui stai cercando di lavorare. Ovviamente sarai frustrato, è nuovo, non è familiare e sei ridotto allo status di principiante tutto da capo. Non c'è modo di evitarlo.

Nel tuo caso particolare ci sono alcuni strumenti aggiuntivi di cui dovresti essere a conoscenza. Il primo è DDD , un front end della GUI per gdb. Non è perfetto come Visual Studio, ma ti manterrà la mano. Tuttavia, consiglierei davvero di mordere il proiettile e di imparare a conoscere i dettagli di gdb. In verità, se sei un utente normale, non c'è molta differenza tra memorizzare i comandi da digitare e memorizzare la finestra di dialogo che devi visualizzare per modificare un'impostazione.

Devi anche conoscere strumenti come CScope e CTags . Per quanto tu possa resistere, ti suggerirei di imparare VIM o Emacs . Si integrano bene con gli strumenti di tag che ho appena menzionato. Paese che vai, usanze che trovi. Puoi trovare estensioni per VIM ed EMACS che faranno il completamento del codice per te. La mia esperienza con gli strumenti che offrono il completamento del codice è che sì, fa risparmiare un po 'di digitazione, ma in generale la digitazione è semplice. Pensare è ciò che è difficile. La tua opinione potrebbe essere diversa, soprattutto se hai la sindrome del tunnel carpale.

Per quanto riguarda il make. Make è certamente orribile, ma probabilmente dovresti succhiarlo e impararlo.

I have been developing Windows applications in C++ for like 10 years now. And recently I've started digging into some Linux projects, and I can't stand how unproductive I am...

Is there something that I'm missing that could make me more productive?

Sviluppa su Windows, distribuisci su Linux.

Questo include i test delle unità in esecuzione sia sulla tua macchina (Windows), sia sul build server (Linux).

Come effetto collaterale, imparerai come scrivere codice portatile.

Un altro effetto positivo è che l'utilizzo di compilatori diversi genererà più avvisi e quindi catturerà più bug.

UPDATE : a tutti i fanboy di Linux che fanno downvoting di questa risposta: non dico che tutti dovrebbero svilupparsi su Windows! Ma utilizzare la piattaforma che conosci molto bene è più produttivo di spendere un sacco di tempo per imparare una nuova piattaforma.

Il tuo problema è stato risolto molte volte nel mondo Linux, tuttavia, a differenza degli strumenti di Windows / Microsoft, non verrà consegnato su un piatto d'argento con un contorno di extra. Potrebbe essere necessario fare del lavoro per ottenerlo.

Uso un editor commerciale (Visual Slick Edit, che è considerato costoso da coloro che non valutano il proprio tempo quanto me) per questo problema esatto. Eclipse con il plugin CDT è un modo open source per andare che ha giustificato un vasto seguito. (Non va bene per me perché ho spesso bisogno del supporto ADA)

Quello che non faccio provano a decodificare i makefile in una sorta di progetto. Uso i sistemi di compilazione IDE e aggiungo / rimuovi manualmente i file in base alle esigenze. Sono sicuro di poterlo scrivere, ma probabilmente non ne vale la pena. Per questo ho trovato eclissi un po 'meno utilizzabili di Slickedit (che potrebbe facilmente (e probabilmente lo è) essere cambiato dall'ultima volta che ho guardato)

Linux ha una vasta gamma di strumenti, i ragazzi che conoscono bene vi superano le mie prestazioni in tutti gli aspetti dell'editing, hanno ricerche di riferimenti ecc., solo una curva di apprendimento ripida. Sono certo che Emacs può fare tutto così, anche se non l'ha mai usato.

Per quel che vale, su Linux hai sistemi di costruzione migliori del semplice vecchio GNU make (che spesso va con l'orribile autoconf ), ad esempio omake e molti altri ( cmake , scons ...).

un suggerimento su quanto sia noioso usare grep per cercare il codice: imposta gli alias bash nel tuo file .bashrc. Quindi, è solo un singolo comando:

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

ci sono probabilmente modi migliori per scrivere il comando, ma l'idea è la stessa. Vuoi codice di ricerca? scrivi un alias chiamato searchCode. Ricorda che, sebbene siano noiosi e complicati, gli strumenti Unix possono anche essere usati per semplificarti la vita.

My 2c come qualcuno che ha sviluppato C ++ su entrambe le piattaforme e gli piace entrambi.

1) I makefile sono dolorosi - il consiglio migliore che posso darti è provare a passare a un altro sistema di build, se possibile.

2) Per la modifica e la navigazione del codice, ci sono alcuni strumenti molto utili. Certo, non sono integrati, ma non importa quando si tratta di fare le cose. vim + ctags + grep ti porterà lì. Naturalmente, ci sono anche IDE, ma sinceramente non mi è piaciuto tutto ciò che ho provato: Eclipse + CDT, KDevelop, Code :: Block. Potresti giungere a conclusioni diverse, però.

3) Per il debug, basta attenersi a gdb da riga di comando. Certo, è piuttosto dietro a Windbg quando si tratta di funzionalità, ma per la maggior parte degli scopi va bene. I front-end grafici (ddd, KDbg) erano piuttosto buggati l'ultima volta che li ho provati, ma di nuovo le cose potrebbero essere cambiate :)

La linea di fondo è - sì, è necessario mettere un po 'di sforzo di apprendimento, ma dopo sarete produttivi quanto Windows.

Per tutti gli altri buoni consigli che hai già ricevuto, vorrei aggiungere un paio di collegamenti, rispettivamente ack e PSS .

Sono rivolti a programmatori che devono preoccuparsi specificamente del codice sorgente, cercando di migliorare oltre grep.

Grandi risposte. Aggiungendo a loro,

Quando ho fatto questa mossa, l'errore che ho fatto è stato provare a saltare nel codice senza dare la dovuta diligenza al sistema di build GNU, che è tornato a mordermi quando volevo apportare modifiche al codice. Trascorri un paio di giorni per capire come funzionano gli strumenti AutoMake / AutoConf / Make di strumenti, dopodiché sarai molto veloce.

Per quanto riguarda gli strumenti - Eclipse + CDT / GDB + DDD va davvero molto lontano.

Ecco alcuni consigli per farlo funzionare più facilmente:

1. Inizia dall'inizio. Ciò significa che userete lo script di bash come sostituto di makefile e poi semplici makefile una volta che avrete bisogno di dipendenze. Mantienilo semplice all'inizio. Il tuo makefile non ha bisogno di gestire 15 diverse piattaforme Unix - basta farlo compilare con le dipendenze. (il tuo makefile iniziale sarà simile a: all: g ++ -o main main.cpp) (un esempio più complesso può essere trovato da link - quando si inizia da zero, basta copiare il file nel progetto, cambiare i nomi dei file, la directory mkdir objs, cambiare le librerie desiderate)
2. Dimentica l'IDE. Ti farà solo rallentare. Impara a leggere il codice e ricorda la gerarchia dei file del tuo progetto. Gli strumenti normali della linea di comando come "cd dir" e "emacs foo.cpp" devono essere così automatici da non pensarci due volte a scriverlo.
3. Dimentica l'evidenziazione della sintassi e l'intelligenza. Non funzionerà mai nello stesso modo in cui funziona nello studio visivo, e il suggerimento che la sua donazione ti confonderà solo perché è diverso da quello a cui sei abituato. Impara a non fare affidamento su di loro.
4. Gdb è un buon debugger. Otterrai uno stack di chiamate. Non provate nemmeno a fare il giro del codice, non funzionerà molto bene. Usa anche valgrind. Anche i breakpoint sono buoni, ma non fare troppo affidamento su di loro; usato solo raramente con gdb.
5. Se la tua compilation è qualcosa di diverso dal semplice 'make' nella shell, devi riconsiderare il tuo edit-compile-debug-edit -cycle.
6. Ecco un trucco che lo studio visivo non può fare: mostrare contemporaneamente sia il file di intestazione che il file .cpp sullo schermo, in modo che entrambi siano visibili senza sfogliare tra di loro con le schede. Emacs può farlo. Quindi puoi notepad. Visual Studio o IDE non possono.
7. Scopri le combinazioni di tasti emacs. Ti renderà più veloce. Un buon suggerimento è che tutti i tasti si trovano molto vicino nella tastiera. Le sequenze di comando sono più lunghe, ma è ancora più veloce digitarle.
8. C'è un trucco facile da sostituire a go-to-definition: scrivi il codice nello stesso file e usa esc- < e C-s :: myfunction in emacs per trovare la funzione desiderata. Il processo è diverso se hai usato molti file brevi - il tuo codice avrà un aspetto diverso. (impara ctrl-f nel blocco note e otterrai l'idea). Ma sicuramente non hai bisogno di farlo in shell.
9. Il tempo di avvio dell'editor di testo è molto importante. Se ci vuole più di 1 secondo per aprirlo, non va bene. Ogni IDE è rotto a causa di questo requisito. Blocco note ed emacs sono ok.
10. goto-line in emacs è una funzionalità importante per la programmazione. Legalo a qualche chiave. Io uso C-x g