Sta usando direttamente Rendi considerato obsoleto? [chiuso]

La grande differenza è che CMake è un sistema di meta-build multipiattaforma . Un singolo progetto CMake può produrre il solito makefile Unix / Linux, un progetto Visual Studio per Windows, un progetto XCode per Mac e quasi tutti gli altri sistemi non di meta build che potresti voler utilizzare o supportare.

Non direi che usare make direttamente o anche manualmente modificare i makefile è "obsoleto", ma sono cose che probabilmente non dovresti fare a meno che tu non stia lavorando su cose Unix / Linux che non avranno bisogno di porting su Windows, come se non dovessi modificare direttamente i file di progetto di Visual Studio se vuoi portarli su not-Windows. Se sei interessato alla portabilità, vale la pena imparare un sistema di meta-build come Scons o CMake.

make è davvero obsoleto?

Io non la penso così Alla fine, make è ancora abbastanza potente da fornire tutte le funzionalità desiderate, come la compilazione condizionale della sorgente modificata e simili. Dire che make era obsoleto, sarebbe come dire che scrivere script di linker personalizzati non era aggiornato.

Ma ciò che% grezzo non fornisce, sono funzionalità estese e librerie di riserva per comodità, come generazione di intestazione parametrica, framework di test integrato o anche solo librerie condizionali in generale.

D'altra parte, make è direttamente adattato alla generazione di librerie ed eseguibili ELF generici. Ogni volta che ti allontani dalle loro procedure predefinite, devi iniziare a hackerare CMake proprio come hai usato per hackerare i tuoi Makefile.

Considerando che è possibile creare molto più in C ++ della semplice applicazione media per un sistema che conosce i caricatori ELF, CMake sicuramente non è adatto a tutti gli scenari. Tuttavia, se stai lavorando in un ambiente standardizzato, CMake o qualsiasi altro di questi moderni framework di generatori di script sono sicuramente i tuoi migliori amici.

Dipende sempre da quanto è specializzata la tua applicazione, e quanto bene la struttura del framework CMake si adatta al tuo flusso di lavoro.

C'era una volta che i linguaggi di alto livello erano solo un'idea. Le persone hanno cercato di implementare i compilatori. All'epoca esistevano gravi limitazioni hardware: non c'erano strumenti grafici, quindi "testo semplice" veniva utilizzato per il formato del file di input; i computer in genere avevano una quantità estremamente piccola di RAM, quindi il codice sorgente doveva essere suddiviso in parti e il compilatore veniva diviso in utilità separate (pre-processore, compilatore, assemblatore, linker); Le CPU erano lente e costose quindi non si potevano fare ottimizzazioni costose, ecc.

Naturalmente con molti file sorgente e molte utilità utilizzate per creare molti file oggetto, è un disastro creare qualcosa manualmente. Come soluzione per i difetti di progettazione degli strumenti (causati da hardware severamente limitato), le persone hanno iniziato a scrivere script per rimuovere alcuni problemi.

Purtroppo, le sceneggiature erano scomode e disordinate. Per aggirare i problemi con gli script (che erano una soluzione per i difetti di progettazione degli strumenti causati da hardware limitato) alla fine le persone hanno inventato le utilità per semplificare le cose, come make .

Tuttavia; i makefile sono scomodi e disordinati. Per aggirare i problemi con i makefile (che erano una soluzione per risolvere i difetti di progettazione degli strumenti causati da hardware limitato), le persone hanno iniziato a sperimentare con i makefile generati automaticamente; a partire da cose come ottenere il compilatore per generare dipendenze; e aprendo a strumenti come auto-conf e cmake.

Questo è il punto in cui ci troviamo ora: soluzioni per un work-around per un work-around per i difetti di progettazione degli strumenti causati da hardware limitato.

È mia aspettativa che entro la fine del secolo ci saranno altri livelli di "work-arounds for work-arounds" in cima alla pila esistente. Ironia della sorte, i severi limiti hardware che hanno causato tutto questo sono scomparsi molti decenni fa e l'unica ragione per cui stiamo ancora utilizzando un tale pasticcio arcaico è " questo è come è sempre stato fatto ".

make (lo strumento o l'uso diretto tramite un Makefile) non è obsoleto, in particolare per "piccoli progetti personali" come lo si usa per.

Naturalmente, puoi anche usarlo per progetti più grandi, compresi quelli destinati a piattaforme multiple. Con variabili specifiche della destinazione puoi personalizzare facilmente la modalità di creazione per piattaforme diverse. Al giorno d'oggi, le distribuzioni Linux vengono fornite con toolchain di cross-compiling (ad es. mingw-w64 ) in modo da poter creare un software Windows completo pacchetto (con l'installer, se lo desideri) da Linux, tutto gestito dal tuo Makefile.

Strumenti come cmake e qmake può essere utile, ma non sono privi di problemi. Di solito sono perfetti per costruire un'applicazione stessa insieme a qualsiasi libreria (anche se ho sempre avuto problemi con qmake che fa il controllo della dipendenza tra le librerie e i programmi che li usano), ma faccio sempre fatica con i vincoli di quegli strumenti quando faccio il resto del lavoro (creazione di programmi di installazione, generazione / installazione di documentazione o file di traduzione, esecuzione di cose insolite come trasformare un archivio in una libreria condivisa, ecc.). Tutto questo può essere fatto in make , anche se cose come il monitoraggio delle dipendenze possono richiedere un piccolo sforzo.

Gli IDE come Qt Creator ed Eclipse possono anche importare progetti basati su Makefile, così puoi condividerli con gli sviluppatori di IDE. Penso che l'IDE di Qt Creator sia eccellente come IDE C ++, ma dopo aver trascorso del tempo per diventare più efficace con Emacs, e visto che sto facendo più sviluppo su Ada, mi trovo a preferire Emacs per tutto. Per tornare alla domanda su make , come passaggio post-link nel mio Makefile, aggiorno il mio file TAGS (per navigazione simbolica in Emacs), caricata con M-x visit-tags-table :

find $(SRC_DIR) $(TEST_DIR) -regex ".*\.[ch]\(pp\)?" -print | etags -

O per lo sviluppo di Ada:

find $(SRC_DIR) $(TEST_DIR) -name "*.ad?" -print | etags -

Questa risposta completa la risposta @lxrec.

I makefile possono essere utilizzati per molte cose, non solo per creare un programma / libreria dal codice sorgente. I sistemi di compilazione come CMake o autotools sono progettati per prendere il codice e costruirlo in modo tale da adattarsi alla piattaforma dell'utente (ad esempio trovare le librerie o specificare le opzioni di compilazione corrette). Ad esempio, potresti avere un makefile che aiuta ad automatizzare alcune attività di rilascio, come ad esempio: creare un file zip contenente codice con la versione derivata da git; eseguire test contro il tuo codice; carica detto file zip su un servizio di hosting. Alcuni sistemi di compilazione (come automake) potrebbero fornire un modo semplice per farlo, altri no.

Questo non vuol dire che devi usare makefile per questo, potresti usare un linguaggio di scripting (shell, python ecc.) per tali compiti.

Non penso che la scrittura umana Makefile -s sia obsoleta, specialmente quando:

1. utilizzando POSIX make, che ti offre un Makefile portatile
2. o usando GNU make 4, che offre molte funzionalità molto interessanti, in particolare la scripting del GUILE, che consente di codificare in modo efficiente le fantasiose funzionalità fornite da Makefile generatori (credo che le funzionalità di autotools o Cmake possano essere facilmente scritte dalla personalizzazione di Guile di GNU make). Ovviamente, il prezzo da pagare è richiedere che GNU faccia 4 (non un grosso problema, IMHO).

I makefile non sono obsoleti, nello stesso modo in cui i file di testo non sono obsoleti. Memorizzare tutti i dati in testo semplice non è sempre il modo giusto di fare le cose, ma se tutto ciò che si desidera è una lista di cose da fare, allora un file di testo normale va bene. Per qualcosa di più complicato potresti volere un formato più complicato come Markdown o XML o un formato binario personalizzato o qualsiasi altra cosa nel mezzo, ma per semplici casi il testo in chiaro funziona bene.

Allo stesso modo, se tutto ciò che vuoi è un modo per evitare di scrivere g++ -g src/*.c -o blah -W -Wall -Werror && ./blah tutto il tempo, un Makefile scritto a mano è perfetto!

Se vuoi creare qualcosa che sia altamente portatile, dove non devi gestire tu stesso quella portabilità, probabilmente vorresti qualcosa come Autotools per generare il Makefile giusto per te. Autotools rileverà le funzionalità supportate da varie piattaforme. Un programma scritto in C89 standard costruito con Autotools si compilerà praticamente ovunque.

se il tuo progetto è semplice e contiene pochissimi file, non è necessario alcun file make.

Tuttavia, quando il progetto è complesso, utilizza numerose aree di memoria, ha molti file, quindi è necessario posizionare ogni area di memoria nel punto giusto nella memoria indirizzabile, è altamente desiderabile non ricompilare ogni file ogni volta che un la modifica banale è fatta su un file,

Se vuoi cancellare vecchi file / compile / link / install con la minima quantità di problemi e la possibilità di errori di pressione, il makefile è un vero vantaggio.

Quando si entra nei progetti del "mondo reale" raramente ci sono solo 1 o 2 file, ma piuttosto centinaia di file. un makefile eseguirà sempre le azioni giuste e non azioni non necessarie (dopo che è stato eseguito il debug), quindi devi solo digitare un semplice comando e il makefile fa tutto il lavoro