¿Es mejor especificar archivos fuente con GLOB o cada archivo individualmente en CMake?

CMake ofrece varias formas de especificar los archivos de origen para un destino. Una es usar globbing ( documentación ), por ejemplo:

FILE(GLOB MY_SRCS dir/*)

Otro método es especificar cada archivo individualmente.

¿Qué camino se prefiere? Globbing parece fácil, pero escuché que tiene algunas desventajas.

Revelación completa: Originalmente preferí el enfoque global por su simplicidad, pero a lo largo de los años he llegado a reconocer que enumerar explícitamente los archivos es menos propenso a errores para proyectos grandes de múltiples desarrolladores.

Respuesta original:

Las ventajas del globbing son:

• Es fácil agregar nuevos archivos, ya que solo se enumeran en un lugar: en el disco. No globbing crea duplicación.

• Su archivo CMakeLists.txt será más corto. Esta es una gran ventaja si tiene muchos archivos. No globular te hace perder la lógica CMake entre grandes listas de archivos.

Las ventajas de usar listas de archivos codificados son:

• CMake hará un seguimiento de las dependencias de un nuevo archivo en el disco correctamente: si usamos glob, los archivos que no se hayan bloqueado la primera vez cuando ejecutaste CMake no serán detectados

• Se asegura de que solo se agreguen los archivos que desea. Globbing puede recoger archivos perdidos que no desea.

Para evitar el primer problema, simplemente puede "tocar" el CMakeLists.txt que hace el glob, ya sea utilizando el comando táctil o escribiendo el archivo sin cambios. Esto obligará a CMake a volver a ejecutar y recoger el nuevo archivo.

Para solucionar el segundo problema, puede organizar su código cuidadosamente en directorios, que es lo que probablemente haga de todos modos. En el peor de los casos, puede usar el list(REMOVE_ITEM)comando para limpiar la lista global de archivos:

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

La única situación real en la que esto puede morderte es si estás usando algo como git-bisect para probar versiones anteriores de tu código en el mismo directorio de compilación. En ese caso, es posible que deba limpiar y compilar más de lo necesario para asegurarse de obtener los archivos correctos en la lista. Este es un caso de esquina, y uno en el que ya estás alerta, que en realidad no es un problema.

La mejor manera de especificar archivos fuente en CMake es enumerándolos explícitamente .

Los propios creadores de CMake aconsejan no usar globbing.

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

(No recomendamos usar GLOB para recopilar una lista de archivos fuente de su árbol fuente. Si no cambia el archivo CMakeLists.txt cuando se agrega o elimina una fuente, el sistema de compilación generado no puede saber cuándo pedirle a CMake que se regenere).

Por supuesto, es posible que desee saber cuáles son las desventajas: ¡siga leyendo!

Cuando falla Globbing:

La gran desventaja de globbing es que crear / eliminar archivos no actualizará automáticamente el sistema de compilación.

Si usted es la persona que agrega los archivos, esto puede parecer una compensación aceptable, sin embargo, esto causa problemas a otras personas que construyen su código, actualizan el proyecto desde el control de versiones, ejecutan la compilación y luego se contactan con usted, quejándose de que
"la compilación es roto".

Para empeorar las cosas, la falla generalmente produce algún error de vinculación que no da ninguna pista sobre la causa del problema y se pierde tiempo para solucionarlo.

En un proyecto en el que trabajé, comenzamos a englobar, pero recibimos tantas quejas cuando se agregaron nuevos archivos, que fue una razón suficiente para enumerar explícitamente los archivos en lugar de glob.

Esto también rompe los flujos de trabajo comunes de git
( git bisecty el cambio entre ramas de características).

Por lo tanto, no podría recomendar esto, los problemas que causa superan con creces la conveniencia, cuando alguien no puede construir su software debido a esto, puede perder mucho tiempo para rastrear el problema o simplemente darse por vencido.

Y otra nota, solo recordar tocar CMakeLists.txtno siempre es suficiente, con las compilaciones automatizadas que usan globbing, tuve que ejecutar cmakeantes de cada compilación ya que los archivos podrían haberse agregado / eliminado desde la última compilación *.

Excepciones a la regla:

Hay momentos en que es preferible el pegadizo:

• Para configurar CMakeLists.txtarchivos para proyectos existentes que no usan CMake.
  Es una forma rápida de obtener toda la fuente referenciada (una vez que el sistema de compilación se está ejecutando, reemplace globbing con listas de archivos explícitas).
• Cuando CMake no se utiliza como el sistema de compilación principal , si, por ejemplo, está utilizando un proyecto que no está utilizando CMake y desea mantener su propio sistema de compilación para él.
• Para cualquier situación en la que la lista de archivos cambia con tanta frecuencia que resulta poco práctico mantenerla. En este caso, podría ser útil, pero luego debe aceptar la ejecución cmakepara generar archivos de compilación cada vez para obtener una compilación confiable / correcta (lo que va en contra de la intención de CMake: la capacidad de dividir la configuración de la compilación ) .

* Sí, podría haber escrito un código para comparar el árbol de archivos en el disco antes y después de una actualización, pero esta no es una buena solución y algo mejor le queda al sistema de compilación.

En CMake 3.12, los comandos file(GLOB ...)yfile(GLOB_RECURSE ...) obtuvieron una CONFIGURE_DEPENDSopción que vuelve a ejecutar cmake si el valor del globo cambia. Como esa era la principal desventaja de buscar archivos fuente, ahora está bien hacerlo:

# 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})

Sin embargo, algunas personas aún recomiendan evitar la búsqueda de fuentes. De hecho, la documentación establece:

No recomendamos usar GLOB para recopilar una lista de archivos fuente de su árbol fuente. ... La CONFIGURE_DEPENDSbandera puede no funcionar de manera confiable en todos los generadores, o si se agrega un nuevo generador en el futuro que no pueda soportarlo, los proyectos que lo usen se bloquearán. Incluso si CONFIGURE_DEPENDSfunciona de manera confiable, todavía hay un costo para realizar la verificación en cada reconstrucción.

Personalmente, considero los beneficios de no tener que administrar manualmente la lista de archivos de origen para superar los posibles inconvenientes. Si tiene que volver a cambiar a los archivos de la lista manual, esto se puede lograr fácilmente simplemente imprimiendo la lista de origen global y pegándola nuevamente.

Puede glob con seguridad (y probablemente debería) a costa de un archivo adicional para contener las dependencias.

Agregue funciones como estas en alguna 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)

Y luego ve a pelear:

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

Todavía está analizando las dependencias explícitas (¡y activando todas las compilaciones automatizadas!) Como antes, solo está en dos archivos en lugar de uno.

El único cambio en el procedimiento es después de haber creado un nuevo archivo. Si no se bloquea, el flujo de trabajo consiste en modificar CMakeLists.txt desde Visual Studio y reconstruir, si lo hace, ejecuta cmake explícitamente, o simplemente toca CMakeLists.txt.

¡Especifique cada archivo individualmente!

Utilizo un CMakeLists.txt convencional y un script de Python para actualizarlo. Ejecuto el script de Python manualmente después de agregar archivos.

Vea mi respuesta aquí: https://stackoverflow.com/a/48318388/3929196