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


31

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?


8
Per piccoli progetti personali makeè sufficiente un senza Makefile. Che seccatura?
ott--

8
Ogni pezzo di software disponibile sui miei sistemi FreeBSD, sia desktop che server, ha un Makefile che è stato avviato da 'make'. No. "make" non è obsoleto.
Rob,

3
Le persone sono libere di usare gli IDE, ma se i loro IDE non sono in grado di supportare progetti che usano Makefile quasi 40 anni dopo la loro makeprima scrittura, non dovrebbero aspettarsi che le persone lavorino su questo.
Miglia in rotta

1
Il "discorso obsoleto riguardante make" è solo un sintomo o un punto dolente , non un annuncio di deprecazione. Soprattutto quando non esiste ancora un sostituto totale superiore e tutti gli approcci per ridurre il dolore continuano a essere utilizzati in qualche modo, appena nascosti dagli utenti che sono più inclini al dolore. Sebbene siano state fornite molte buone risposte, la domanda stessa è basata sull'opinione al limite.
rwong

1
CMakeè uno strato di astrazione. Questa astrazione è necessaria per domare la varietà selvaggia di prodotti IDE di consumo che non sono conformi all'open source Makefile. Anche in questo caso non è solo astrazione, ma consente funzionalità di configurazione (come autoconf). Come altre astrazioni, consente alternative . Ma apre la strada a una nuova idea sperimentale di alternative di Makefile facilmente disponibili per gli utenti di CMake.
shuva,

Risposte:


30

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.


9
POSIX makeè anche multipiattaforma.
Blrfl,

6
@Blrfl questo può essere vero, ma generalmente troverai che le linee di comando che devi usare per compilare e / o collegare il tuo progetto sono specifiche della piattaforma, anche se tutte le piattaforme che stai prendendo di mira sono conformi a POSIX e anche se tu stai usando lo stesso compilatore su tutti (ci saranno ancora fastidiosi problemi con le posizioni dei file include, se ne hai bisogno -lm, -lnsle così via o se tali servizi sono inclusi nella libreria C, ecc.).
Jules,

5
@Jules C'è molto di più (o meno) CMake, è sostanzialmente su misura per la creazione della tua applicazione standard standard per sistemi con caricatori ELF e fornisce astrazioni per tutti gli strumenti necessari per quella specifica catena di strumenti. Se ci si allontana da quella toolchain (ad es. Script di linker personalizzati per bare metal), CMakeimprovvisamente non fornisce alcun supporto o portabilità, si finisce per hackerarlo proprio come si usava per hackerare script di build completamente personalizzati.
Ext3h

Lo stesso vale per Q make (nonostante non sia il mal documentato che si comporta in modo incoerente ** ap CMake is), btw;)
mlvljr

11

È 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.


Sebbene utile, make è un sistema orribile con cervello duro, sintassi arcana e tonnellate di limitazioni inutili che rendono necessari molti momenti di oops.
antred

7

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 ".


1
Qual è l'alternativa? L'alternativa sta cambiando totalmente il concetto di build così come lo conosciamo?
JParrilla,

1
@Darkslash: una volta che inizi a considerare alternative (ipotetiche) è come aprire le porte: finisci per mettere in discussione tutto (e finisci con idee come la separazione di semantica e sintassi, riprogettazione di IDE e strumenti e consegna come un insieme piuttosto che singoli pezzi del puzzle più grande). Più pratico è rendersi conto che strumenti come cmaketrattare solo i sintomi e non possono curare la / le causa / i di radice; il che rende più facile accettare il fatto che non hai altra scelta se non quella di utilizzare strumenti che probabilmente non saranno mai vicini all '"ideale".
Brendan,

5
I makefile non sono in alcun modo "imbarazzanti e disordinati". Sono incredibilmente eleganti: makeè al centro un motore per attraversare un grafico di dipendenza aciclico. Nulla di "script" o della riga di comando è "arcaico".
Miglia in rotta

1
@MilesRout: la parte scomoda e disordinata è la costruzione del grafico. La traversata è abbastanza elegante. Ma prendi solo il singolo esempio più comune della parte disordinata: i file di intestazione C. Ognuno #includeè un vantaggio, ma makenon può analizzare i file C. Non è ancora un problema, perché makepotrebbe archiviare questi bordi con il nodo successivo (il file * .o), ma non lo fa neanche.
Salterio

3
Non sono d'accordo che sia possibile un design migliore. makenon è solo per compilare C! Volete un programma che prende .ce .hfile e dà Makefiles. Ma non è così make, e non è quello che makedovrebbe fare. Ancora una volta, makenon si tratta solo di C, e una soluzione specifica per C integrata makeè una cattiva idea (e per inciso una violazione della filosofia UNIX).
Miglia in rotta

5

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 -

2

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.


1

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).

0

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.


"compilerà praticamente ovunque" -> "compilerà sui più recenti sistemi simili a Unix". Non penso autotoolsche funzioni in modo rilevante su un sistema Windows, ad esempio (scontando Cygwin / MingW, che è in realtà un sistema simile a Unix su Windows).
sleske,

Non ha nulla a che fare con l'essere recenti. Il vantaggio degli autotools è che funziona su ogni sistema remoto simile a POSIX. Windows è in qualche modo conforme a POSIX.
Miglia in rotta il

Sì, sono corretto. In realtà, ricordo che una critica agli autotools è proprio che contiene codice anche per sistemi molto vecchi, quindi gratta il "recente". Rimango comunque al fianco di Windows.
sleske,

E la colpa è interamente di Microsoft. Se si preoccupassero di produrre un prodotto di qualità, Windows avrebbe il supporto adeguato per gli standard dei sistemi operativi internazionali (come POSIX). POSIX non è solo una "cosa Unix", è lo standard del sistema operativo portatile per tutti i sistemi operativi. Windows è solo un mucchio di spazzatura non conforme.
Miles Rout,

@MilesRout è ancora la linea di fondo che "praticamente ovunque" esclude il 90% dei computer desktop .
el.pescado,

-2

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


1
Che non rispondere perché a preferire makesopra cmakeo viceversa.
Ext3h

L'uso di makefile non ricostruisce tutti i file ogni volta. (altrimenti CMake o Auto-tools non potevano usarlo)
ideasman42
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.