Come affrontare efficacemente grandi progetti Linux / makefile?

Sto sviluppando applicazioni Windows in C ++ da circa 10 anni. E recentemente ho iniziato a scavare in alcuni progetti Linux, e non sopporto quanto sono improduttivo ...

Sono uno studente veloce, e sto usando Linux come piattaforma primaria da qualche tempo. E mi sento molto a mio agio con la shell, i principi del sistema operativo e la GUI. Ma quando si tratta di sviluppo, mi sembra di tornare a scuola.

Non appena apro un progetto più grande, sono bloccato. Molti di questi sono basati su makefile, quindi in pratica quando provo a navigare con QT o CodeBlocks, nella migliore delle ipotesi, posso usare intellisense su una base per file. E la maggior parte delle variabili temporali fuoriescono dall'ambito.

Poi c'è una roba da go-to-definition, che sembra inesistente, prova a unirti a qualche progetto più grande di sourceforge e sei bloccato per giorni, perché navigare verso le definizioni è così difficile ... grep -r "this_def" . --include "*.cpp" --include "*.h"sembra così lento e goffo.

E poi, il debugging, gdb funziona, ma qualunque cosa io faccia, sembra che ci siano anni luce dietro il debugger di WinDbg o VisualStudio.

E queste cose mi stanno rendendo disperato, voglio scrivere codice, ma va così lentamente ... Sto iniziando a pensare che gli sviluppatori Linux imparino a memoria le definizioni delle funzioni e analizzino il codice a occhi, ma non riesco a credere che sia così.

Qualcuno ha attraversato questo? C'è qualcosa che mi manca che potrebbe rendermi più produttivo?

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

Muovendosi in entrambe le direzioni, il segreto è avere pazienza e apprendere il set di strumenti per la piattaforma in cui stai cercando di lavorare. Naturalmente sarai frustrato, è nuovo e non ti è 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 che dovresti conoscere. Il primo è DDD , un front-end della GUI per gdb. Non è lucido come Visual Studio, ma ti terrà la mano. Tuttavia, consiglierei davvero di mordere il proiettile e iniziare a imparare i dettagli di gdb. In verità, se sei un utente normale, non c'è molta differenza tra memorizzare quali comandi digitare e memorizzare quale finestra di dialogo devi aprire per cambiare un'impostazione.

È inoltre necessario sapere su strumenti come Cscope e CTags . Per quanto tu possa resistere, suggerirei di imparare VIM o EMACS . Si integrano bene con gli strumenti tag che ho appena menzionato. Paese che vai, usanze che trovi. Puoi trovare estensioni per VIM ed EMACS che completeranno il codice per te. La mia esperienza personale con strumenti che offrono il completamento del codice è che sì, salva un po 'di battitura, ma in genere è facile. Pensare è ciò che è difficile. La tua opinione potrebbe essere diversa, in particolare se hai la sindrome del tunnel carpale.

Per quanto riguarda make. Make è certamente orribile, ma probabilmente dovrai solo succhiarlo e impararlo.

Sto sviluppando applicazioni Windows in C ++ da circa 10 anni. E recentemente ho iniziato a scavare in alcuni progetti Linux, e non sopporto quanto sono improduttivo ...

C'è qualcosa che mi manca che potrebbe rendermi più produttivo?

Sviluppa su Windows, distribuisci su Linux.

Ciò include l'esecuzione di unit test sia sul proprio computer (Windows) che sul server di build (Linux).

Come effetto collaterale, imparerai a scrivere codice portatile.

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

AGGIORNAMENTO : A tutti i fan di Linux che votano in basso questa risposta: non dico che tutti dovrebbero svilupparsi su Windows! Ma usare la piattaforma che conosci molto bene è più produttivo che dedicare molto tempo all'apprendimento di una nuova piattaforma.

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

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

Quello che non faccio è provare a decodificare i makefile in una sorta di progetto. Uso i sistemi integrati dell'IDE e aggiungo / rimuovo manualmente i file secondo necessità. Sono sicuro di poterlo scrivere, ma probabilmente non ne vale la pena. Per questo ho trovato l'eclissi un po 'meno utilizzabile di Slickedit (che avrebbe potuto facilmente (e probabilmente è cambiato) dall'ultima volta che ho guardato)

Linux ha una vasta gamma di strumenti, ragazzi che conoscono bene che mi hanno superato in tutti gli aspetti dell'editing, ha ricerche di riferimenti ecc., Solo una ripida curva di apprendimento. Sono certo che anche Emacs può fare tutto, anche se non l'ho mai usato.

Per quello che vale, su Linux hai sistemi di costruzione migliori rispetto al semplice vecchio GNU (che spesso si accompagna all'orribile autoconf ), ad esempio omake e molti altri ( cmake, scons...).

un suggerimento su quanto sia noioso usare grep per cercare il codice: imposta 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'

probabilmente c'è modo migliore per scrivere il comando, ma l'idea è la stessa. Vuoi cercare il codice? scrivere un alias chiamato searchCode. Ricorda che sebbene siano noiosi e complicati, gli strumenti unix possono anche essere usati per semplificarti la vita.

Il mio 2c come qualcuno che ha sviluppato C ++ su entrambe le piattaforme e le piace entrambe.

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

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

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

La linea di fondo è: sì, devi mettere un po 'di sforzo di apprendimento, ma dopo sarai altrettanto produttivo come sei su Windows.

A tutti gli altri buoni consigli che hai già ricevuto, vorrei aggiungere un paio di link, rispettivamente a ack e pss .

Sono rivolti ai programmatori che devono preoccuparsi in modo specifico del codice sorgente, cercando di migliorare su grep.

Grandi risposte. Aggiungendo a loro,

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

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

Ecco alcuni consigli per farlo funzionare più facilmente:

1. Inizia dall'inizio. Questo significa che utilizzerai prima lo script bash come sostituto del makefile e poi semplici makefile quando avrai bisogno di dipendenze. Mantenerlo semplice all'inizio. Il tuo makefile non ha bisogno di gestire 15 diverse piattaforme unix: basta compilarlo con dipendenze. (il tuo makefile iniziale apparirà come: all: g ++ -o main main.cpp) (esempio più complesso può essere trovato da http://sivut.koti.soon.fi/~terop/Makefile - quando inizi da zero , basta copiare il file nel progetto, cambiare i nomi dei file, la directory mkdir objs, cambiare le librerie che vuoi)
2. Dimentica l'IDE. Ti renderà solo più lento. Impara a leggere il codice e a ricordare la gerarchia dei file del tuo progetto. I normali strumenti a riga di comando come 'cd dir' e 'emacs foo.cpp' devono essere così automatici che non pensi di digitarlo due volte.
3. Dimentica l'evidenziazione della sintassi e l'intellisense. Non funzionerà mai nello stesso modo in cui funziona su Visual Studio e i suggerimenti che il suo dare ti confonderanno solo perché è diverso da quello a cui sei abituato. Impara a non fare affidamento su di loro.
4. Gdb è un buon debugger. Riceverai uno stack di chiamate. Non tentare nemmeno di aggirare il codice, non funzionerà molto bene. Usa anche valgrind. Anche i punti di interruzione sono buoni, ma non fare troppo affidamento su di essi; usato solo raramente con gdb.
5. Se la tua compilation è qualcosa di diverso dal semplice "make" nella shell, devi ripensare il tuo edit-compilare-debug-modificare-ciclo.
6. Ecco un trucco che Visual Studio non può fare: mostra contemporaneamente sia il file di intestazione che il file .cpp sullo schermo, in modo che entrambi siano visibili senza passare da una scheda all'altra. Emacs può farlo. Quindi può blocco note. Visual Studio o IDE non possono.
7. Scopri le combinazioni di tasti di emacs. Ti renderà più veloce. Un bel suggerimento è che tutti i tasti si trovano molto vicino alla tastiera. Le sequenze di comandi sono più lunghe, ma è ancora più veloce digitarle.
8. C'è un semplice trucco per sostituire la go-to-definition: scrivere il codice nello stesso file e usare esc- <e Cs :: myfunction in emacs per trovare la funzione desiderata. Il processo è diverso se hai utilizzato molti file brevi: il tuo codice apparirà diverso. (impara ctrl-f nel blocco note e otterrai l'idea). Ma sicuramente non è necessario farlo nella 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 viene interrotto a causa di questo requisito. Blocco note ed emacs sono ok.
10. goto-line in emacs è una caratteristica importante per la programmazione. Legalo a qualche chiave. Uso Cx g