È meglio specificare i file di origine con GLOB o ciascun file singolarmente in CMake?

CMake offre diversi modi per specificare i file di origine per una destinazione. Uno è usare il globbing ( documentazione ), ad esempio:

FILE(GLOB MY_SRCS dir/*)

Un altro metodo è quello di specificare ogni file singolarmente.

Quale modo è preferito? Il globbing sembra facile, ma ho sentito che ha degli aspetti negativi.

Divulgazione completa: originariamente ho preferito l'approccio globbing per la sua semplicità, ma nel corso degli anni sono arrivato a riconoscere che elencare esplicitamente i file è meno soggetto a errori per grandi progetti multi-sviluppatore.

Risposta originale:

I vantaggi del globbing sono:

• È facile aggiungere nuovi file poiché sono elencati in un solo posto: su disco. Non globbing crea duplicazioni.

• Il tuo file CMakeLists.txt sarà più breve. Questo è un grande vantaggio se hai molti file. Non alterare fa perdere la logica di CMake tra enormi elenchi di file.

I vantaggi dell'utilizzo di elenchi di file codificati sono:

• CMake monitorerà correttamente le dipendenze di un nuovo file sul disco: se utilizziamo glob, i file non vengono sottoposti a globbing la prima volta che hai eseguito CMake non verrà rilevato

• Ti assicuri che vengano aggiunti solo i file che desideri. Globbing può raccogliere file vaganti che non si desidera.

Per aggirare il primo problema, puoi semplicemente "toccare" il CMakeLists.txt che fa il glob, usando il comando touch o scrivendo il file senza modifiche. Ciò costringerà CMake a rieseguire e raccogliere il nuovo file.

Per risolvere il secondo problema, puoi organizzare attentamente il tuo codice in directory, che è probabilmente quello che fai comunque. Nel peggiore dei casi, è possibile utilizzare il list(REMOVE_ITEM)comando per ripulire l'elenco di file distorto:

file(GLOB to_remove file_to_remove.cpp)
list(REMOVE_ITEM list ${to_remove})

L'unica vera situazione in cui questo può morderti è se stai usando qualcosa come git-bisect per provare versioni precedenti del tuo codice nella stessa directory di build. In tal caso, potrebbe essere necessario pulire e compilare più del necessario per assicurarsi di ottenere i file giusti nell'elenco. Questo è un caso così grave, e uno in cui sei già in punta di piedi, che non è davvero un problema.

Il modo migliore per specificare i file sorgente in CMake è elencarli esplicitamente .

I creatori di CMake stessi consigliano di non usare il globbing.

Vedi: https://cmake.org/cmake/help/v3.15/command/file.html?highlight=glob#file

(Non è consigliabile utilizzare GLOB per raccogliere un elenco di file di origine dall'albero dei sorgenti. Se nessun file CMakeLists.txt cambia quando viene aggiunta o rimossa una fonte, il sistema di generazione generato non può sapere quando chiedere a CMake di rigenerarsi.)

Naturalmente, potresti voler sapere quali sono gli svantaggi: continua a leggere!

Quando Globbing fallisce:

Il grande svantaggio del globbing è che la creazione / eliminazione di file non aggiorna automaticamente il sistema di compilazione.

Se sei la persona che aggiunge i file, questo può sembrare un compromesso accettabile, tuttavia ciò causa problemi ad altre persone che costruiscono il tuo codice, aggiornano il progetto dal controllo della versione, eseguono build, quindi contattano, lamentandoti che
creano il "la build è rotto".

A peggiorare le cose, il fallimento in genere dà qualche errore di collegamento che non fornisce alcun suggerimento per la causa del problema e il tempo viene perso per risolvere il problema.

In un progetto su cui ho lavorato abbiamo iniziato a fare globbing ma abbiamo ricevuto così tante lamentele quando sono stati aggiunti nuovi file, che era una ragione sufficiente per elencare esplicitamente i file invece di globbing.

Ciò interrompe anche i flussi di lavoro comuni di git
( git bisecte il passaggio tra i rami delle caratteristiche).

Quindi non potrei raccomandarlo, i problemi che causa superano di gran lunga la convenienza, quando qualcuno non può costruire il tuo software per questo motivo, potrebbero perdere molto tempo per rintracciare il problema o semplicemente rinunciare.

E un'altra nota, Ricordare di toccare CMakeLists.txtnon è sempre abbastanza, con build automatizzate che usano il globbing, ho dovuto correre cmakeprima di ogni build poiché i file potrebbero essere stati aggiunti / rimossi dall'ultimo edificio *.

Eccezioni alla regola:

Ci sono momenti in cui è preferibile il globbing:

• Per impostare un CMakeLists.txtfile per progetti esistenti che non usano CMake.
  È un modo veloce per ottenere tutti i sorgenti referenziati (una volta che il sistema di compilazione è in esecuzione - sostituisci globbing con elenchi di file espliciti).
• Quando CMake non viene utilizzato come sistema di compilazione principale , ad esempio se si utilizza un progetto che non utilizza CMake e si desidera mantenere il proprio sistema di compilazione.
• Per ogni situazione in cui l'elenco dei file cambia così spesso che diventa poco pratico da mantenere. In questo caso potrebbe essere utile, ma poi devi accettare l'esecuzione cmakeper generare file di build ogni volta per ottenere una build affidabile / corretta (che va contro l'intenzione di CMake - la possibilità di dividere la configurazione dalla costruzione) .

* Sì, avrei potuto scrivere un codice per confrontare l'albero dei file sul disco prima e dopo un aggiornamento, ma questa non è una soluzione così piacevole e qualcosa di meglio lasciato al sistema di compilazione.

In CMake 3.12, i comandi file(GLOB ...)e hannofile(GLOB_RECURSE ...) ottenuto CONFIGURE_DEPENDSun'opzione che ripete cmake se il valore del glob cambia. Dato che quello era lo svantaggio principale del globbing per i file di origine, ora va bene farlo:

# Whenever this glob's value changes, cmake will rerun and update the build with the
# new/removed files.
file(GLOB_RECURSE sources CONFIGURE_DEPENDS "*.cpp")

add_executable(my_target ${sources})

Tuttavia, alcune persone raccomandano ancora di evitare di perdere tempo per le fonti. Infatti, la documentazione afferma:

Non è consigliabile utilizzare GLOB per raccogliere un elenco di file di origine dall'albero dei sorgenti. ... La CONFIGURE_DEPENDSbandiera potrebbe non funzionare in modo affidabile su tutti i generatori, o se in futuro verrà aggiunto un nuovo generatore che non può supportarlo, i progetti che lo utilizzano verranno bloccati. Anche se CONFIGURE_DEPENDSfunziona in modo affidabile, c'è comunque un costo per eseguire il controllo su ogni ricostruzione.

Personalmente, considero i vantaggi di non dover gestire manualmente l'elenco dei file di origine per superare gli eventuali inconvenienti. Se è necessario tornare ai file elencati manualmente, questo può essere facilmente ottenuto semplicemente stampando l'elenco di fonti globbed e incollandolo nuovamente.

Puoi tranquillamente glob (e probabilmente dovrebbe) al costo di un file aggiuntivo per contenere le dipendenze.

Aggiungi funzioni come queste da qualche parte:

# Compare the new contents with the existing file, if it exists and is the 
# same we don't want to trigger a make by changing its timestamp.
function(update_file path content)
    set(old_content "")
    if(EXISTS "${path}")
        file(READ "${path}" old_content)
    endif()
    if(NOT old_content STREQUAL content)
        file(WRITE "${path}" "${content}")
    endif()
endfunction(update_file)

# Creates a file called CMakeDeps.cmake next to your CMakeLists.txt with
# the list of dependencies in it - this file should be treated as part of 
# CMakeLists.txt (source controlled, etc.).
function(update_deps_file deps)
    set(deps_file "CMakeDeps.cmake")
    # Normalize the list so it's the same on every machine
    list(REMOVE_DUPLICATES deps)
    foreach(dep IN LISTS deps)
        file(RELATIVE_PATH rel_dep ${CMAKE_CURRENT_SOURCE_DIR} ${dep})
        list(APPEND rel_deps ${rel_dep})
    endforeach(dep)
    list(SORT rel_deps)
    # Update the deps file
    set(content "# generated by make process\nset(sources ${rel_deps})\n")
    update_file(${deps_file} "${content}")
    # Include the file so it's tracked as a generation dependency we don't
    # need the content.
    include(${deps_file})
endfunction(update_deps_file)

E poi vai a ballare:

file(GLOB_RECURSE sources LIST_DIRECTORIES false *.h *.cpp)
update_deps_file("${sources}")
add_executable(test ${sources})

Stai ancora cercando le dipendenze esplicite (e attivando tutte le build automatizzate!) Come prima, solo in due file anziché in uno.

L'unica modifica alla procedura è dopo aver creato un nuovo file. Se non globalmente il flusso di lavoro consiste nel modificare CMakeLists.txt da Visual Studio e ricostruirlo, se lo fai glob esegui esplicitamente cmake - o semplicemente tocca CMakeLists.txt.

Specifica ogni file singolarmente!

Uso un CMakeLists.txt convenzionale e uno script Python per aggiornarlo. Eseguo manualmente lo script Python dopo aver aggiunto i file.

Vedi la mia risposta qui: https://stackoverflow.com/a/48318388/3929196