¿Es mejor especificar los archivos de origen con GLOB o cada archivo individualmente en CMake?

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

Los creadores de CMake aconsejan no usar globbing.

Véase: http://www.cmake.org/cmake/help/v3.3/command/file.html?highlight=glob#file

(No recomendamos usar GLOB para recopilar una lista de archivos fuente de su árbol de fuentes. Si no CMakeLists.el archivo txt cambia cuando se agrega o elimina una fuente, entonces 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 el Globbing:

La gran desventaja de globbing es que la creación/eliminación de 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 para otras personas que construyen su código, actualizan el proyecto desde el control de versiones, ejecutar build, a continuación, en contacto con usted, quejándose de que
"the build's broken"(en inglés).

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

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

Esto también rompe el git común flujos de trabajo
(git bisect y cambiar entre ramas de características).

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

Y otra nota, recordar tocar CMakeLists.txt no siempre es suficiente, con compilaciones automatizadas que usan globbing, tuve que ejecutar cmake antes de cada compilación ya que los archivos podrían haber sido añadido / eliminado desde el último edificio *.

Excepciones a la regla:

Hay momentos en los que el globbing es preferible:

• Para configurar archivos CMakeLists.txt para proyectos existentes que no usan CMake.
  Es una forma rápida de obtener toda la fuente referenciada (una vez que se ejecuta el sistema de compilación, reemplace la globbing con listas de archivos explícitas).
• Cuando CMake no se usa como el sistema de compilación primario, si, por ejemplo, está utilizando un proyecto que no está usando CMake, y le gustaría mantener su propio sistema de construcción para ello.
• Para cualquier situación en la que la lista de archivos cambia tan a menudo que resulta poco práctico mantenerla. En este caso podría ser útil, pero entonces tienes que aceptar ejecutar cmake para 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 construcció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 esto no es una buena solución y algo mejor dejado hasta el sistema de compilación.

Puede glob de forma segura (y probablemente debería) al costo de un archivo adicional para mantener las dependencias.

Agregue funciones como estas en algún lugar:

# 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 ir globbing:

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

Todavía estás rastreando las dependencias explícitas (¡y activando todas las compilaciones automatizadas!) como antes, solo que 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 globaliza el flujo de trabajo es modificar las listas de CMakeLists.txt desde dentro de Visual Studio y rebuild, si hace glob, ejecute cmake explícitamente , o simplemente toque las listas de CMakeLists.txt.

Especifique cada archivo individualmente!

Utilizo una lista de CMakeLists convencional.txt y un script python para actualizarlo. Corro el script de python manualmente después de agregar archivos.

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