L'uso diretto di Make è considerato obsoleto? [chiuso]

Quindi mi sono imbattuto in molti commenti / post / ecc riguardo alla creazione diretta di makefile e su come sia una cosa sciocca da fare nel 2015. Sono a conoscenza di strumenti come CMake e in realtà uso CMake abbastanza spesso. Il fatto è che CMake sta semplicemente creando il Makefile per te e ti aiuta a rimuovere il tedio di farlo da solo. Ovviamente aggiunge molte altre fantastiche funzionalità ... ma alla fine è ancora un Makefile.

Quindi la mia domanda è: il discorso 'obsoleto' riguardante make si riferisce all'intera utility Make, o solo l'idea di scrivere manualmente i tuoi Makefile? Non uso affatto un IDE per lo sviluppo C / C ++ (solo emacs), quindi ho sempre scritto Makefile.

Se Make è considerato obsoleto, cosa dovrebbe usare uno sviluppatore C / C ++ per costruire piccoli progetti personali?

La grande differenza è che CMake è un sistema 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 qualsiasi altro sistema non meta-build che potresti voler utilizzare o supportare.

Non direi che usare make direttamente o anche modificare manualmente i makefile sia "obsoleto", ma quelle 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, proprio come il tuo non dovresti modificare direttamente i file di progetto di Visual Studio se desideri portarli su non Windows. Se sei interessato alla portabilità, vale la pena imparare un sistema di meta-build come Scons o CMake.

È makedavvero obsoleto?

Io non la penso così. Alla fine, make è ancora abbastanza potente da fornire tutte le funzionalità desiderate, come la compilazione condizionale di sorgenti modificate e simili. Dire che makeera obsoleto, equivale a dire che scrivere script di linker personalizzati era obsoleto.

Ma ciò che Raw makenon fornisce, sono funzionalità estese e librerie di stock per il massimo comfort, come la generazione di header parametrici, framework di test integrati o persino solo librerie condizionali in generale.

D'altra parte, CMakeè direttamente su misura per la generazione di librerie ed eseguibili ELF generici. Ogni volta che ci si allontana dalle procedure predefinite, è necessario iniziare l'hacking CMakeproprio come si usava per hackerare i propri Makefile.

Considerando che è possibile creare molto di più in C ++ rispetto alla semplice applicazione media per un sistema che conosce i caricatori ELF, CMakesicuramente non è adatto a tutti gli scenari. Tuttavia, se stai lavorando in un ambiente così standardizzato, CMakeo qualsiasi altro di questi moderni framework di generatori di script, sicuramente sei il tuo migliore amico.

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

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

Ovviamente con molti file sorgente e molte utilità utilizzate per creare molti file oggetto, è un casino costruire qualcosa manualmente. Come soluzione per i difetti di progettazione degli strumenti (causati da hardware gravemente limitato), le persone hanno naturalmente iniziato a scrivere script per rimuovere alcune seccature.

Purtroppo, gli script erano imbarazzanti e disordinati. Per ovviare ai problemi con gli script (che erano una soluzione per i difetti di progettazione negli strumenti causati da hardware limitato) alla fine le persone hanno inventato utility per rendere le cose più facili, come make.

Tuttavia; i makefile sono scomodi e disordinati. Per ovviare ai problemi con i makefile (che erano una soluzione per una soluzione per i difetti di progettazione negli strumenti causati da hardware limitato) le persone hanno iniziato a sperimentare con i makefile generati automaticamente; a partire da cose come far sì che il compilatore generi dipendenze; e porta a strumenti come auto-conf e cmake.

Questo è dove siamo ora: soluzioni alternative per soluzioni alternative per difetti di progettazione negli strumenti causati da hardware limitato.

Mi aspetto che entro la fine del secolo ci saranno altri strati di "aggiramenti per aggirare" in cima alla pila esistente. Ironia della sorte, i gravi limiti hardware che hanno causato tutto questo sono scomparsi molti decenni fa e l'unica ragione per cui stiamo ancora usando un casino così arcaico ora è " questo è come è sempre stato fatto ".

make (lo strumento o l'uso diretto di esso tramite un Makefile) non è obsoleto, in particolare per "piccoli progetti personali" per i quali lo usi.

Naturalmente, puoi anche usarlo per progetti più grandi, compresi quelli destinati a più piattaforme. Con le variabili specifiche del target puoi facilmente personalizzare il modo in cui costruisci per piattaforme diverse. Al giorno d'oggi, le distribuzioni Linux sono dotate di toolchain cross-compilation (ad esempio mingw-w64 ) in modo da poter creare un pacchetto software Windows completo (con installer se lo si desidera) da Linux, tutto guidato dal tuo Makefile.

Strumenti come cmake e qmake possono essere utili, ma non sono privi di problemi. Di solito vanno bene per la creazione di un'applicazione stessa insieme a qualsiasi libreria (anche se ho sempre avuto problemi con qmake nel fare il corretto controllo delle dipendenze 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, operazioni insolite come la trasformazione di un archivio in una libreria condivisa, ecc.). Tutto ciò può essere fatto 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, in modo da poterli condividere con gli sviluppatori che utilizzano IDE. Penso che l'IDE Qt Creator sia eccellente come IDE C ++, ma dopo aver trascorso un po 'di tempo a diventare più efficace con Emacs, e dal momento che sto facendo più sviluppo 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 la navigazione dei simboli in Emacs), caricato 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 integra la risposta @lxrec.

I makefile possono essere usati 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 crearlo in modo tale da adattarsi alla piattaforma dell'utente (ad esempio, trovare librerie o specificare le opzioni di compilazione corrette). Ad esempio, potresti avere un makefile che aiuta ad automatizzare alcune attività di rilascio, come: creare un file zip contenente codice con la versione derivata da git; eseguire test con il tuo codice; caricare detto file zip in alcuni servizi 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 gli scritti umani Makefilesiano obsoleti, specialmente quando:

1. usando POSIX make, che ti dà un portatile Makefile
2. o usando GNU make 4, che ti offre molte caratteristiche molto interessanti, in particolare la scriptabilità di GUILE, che consente di codificare in modo efficiente le fantasiose funzionalità fornite dai Makefilegeneratori (credo che le funzionalità di autotools o Cmake potrebbero essere facilmente scritte dalla personalizzazione di Guile di GNU make ). Naturalmente, il prezzo da pagare è richiedere a GNU make 4 (non è un grosso problema, IMHO).

I makefile non sono obsoleti, allo 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 vuoi è un Elenco Todo, allora un file di testo semplice 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 via di mezzo, ma per casi semplici il testo normale 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 && ./blahsempre, un Makefile scritto a mano è perfetto!

Se vuoi costruire qualcosa che sia altamente portatile, dove non devi gestire tu stesso quella portabilità, probabilmente vuoi qualcosa come Autotools per generare il Makefile giusto per te. Gli autotools rileveranno le funzionalità supportate da varie piattaforme. Un programma scritto nello standard C89 costruito con Autotools verrà compilato praticamente ovunque.

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

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 cambiamento banale è creato in un unico file,

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

Quando entri nel "mondo reale" i progetti raramente sono solo 1 o 2 file, ma piuttosto centinaia di file. un makefile eseguirà sempre le azioni giuste e nessuna azione non necessaria (dopo il debug) in modo da digitare un solo comando e il makefile fa tutto il lavoro