cmake glob

¿Por qué el archivo cmake GLOB es malo?



(4)

Además de las razones por las que otras personas aquí publicaron, el problema más grave con glob es que puede generar DIFERENTES listas de archivos en diferentes plataformas. Como yo lo veo, eso es un error. En OSX, glob ignora la sensibilidad a las mayúsculas y en una caja de ubuntu no.

El documento CMake dice acerca del archivo de comando GLOB :

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

Varios hilos de discusión en la web indican que los archivos de origen de globbing son malos.

Sin embargo, para que el sistema de compilación sepa que se ha agregado o eliminado una fuente, es suficiente decir

touch CMakeLists.txt

¿Derecha?

Entonces eso es menos esfuerzo que editar CMakeLists.txt para insertar o eliminar un nombre de archivo de origen. Tampoco es más difícil de recordar. Entonces no veo ninguna buena razón para desaconsejar el file GLOB .

¿Qué hay de malo con este argumento?


El problema es cuando no estás solo trabajando en un proyecto.

Digamos que el proyecto tiene desarrollador A y B.

A agrega un nuevo archivo fuente xc . No cambia CMakeLists.txt y se compromete después de que haya terminado de implementar xc .

Ahora B hace un git pull , y como no se han realizado modificaciones a CMakeLists.txt , CMake no se ejecuta de nuevo y B causa errores de vinculador al compilar, porque xc no se ha agregado a su lista de archivos de origen.


Globbing rompe toda inspección de código en cosas como CLion que, de lo contrario, comprenden subconjuntos limitados de CMakeLists.txt y no lo hacen, y nunca lo harán, ya que no son seguros.

Escribir guiones para volcar la lista de globbeds y pegarla, es muy simple, y luego CLion puede encontrar los archivos de referencia e inferirlos como útiles. Tal vez incluso coloque ese script en el árbol para que los otros desarrolladores puedan ejecutarlo sin ser un imbécil O O establecer ganchos de git para que esto suceda.

En ningún caso, un archivo aleatorio introducido en algún directorio debe vincularse automáticamente, así es como suceden los troyanos.

También CLion sin contexto, saltando a definiciones conocidas y lo que no, es como caminar descalzo /// por qué molestarse.


No es intrínsecamente malo, tiene ventajas y desventajas, se cubre relativamente bien en esta respuesta aquí en . Pero si lo usa sin cuidado, podría terminar ignorando los cambios de dependencia y requiriendo reconstrucciones limpias de grandes partes de su base de código.

Personalmente estoy a favor de usarlo, en proyectos más pequeños o en ciertos subdirectorios en proyectos más grandes, para evitar tener que ingresar manualmente todos los archivos en los archivos de compilación. Edición: mi preferencia ha cambiado y actualmente tiendo a evitarla.