Est-il préférable de spécifier les fichiers source avec GLOB ou chaque fichier individuellement dans CMake?

CMake propose plusieurs façons de spécifier les fichiers source d'une cible. La première consiste à utiliser le globbing ( documentation ), par exemple:

FILE(GLOB MY_SRCS dir/*)

Une autre méthode consiste à spécifier chaque fichier individuellement.

Quelle voie est préférée? Globbing semble facile, mais j'ai entendu dire que cela avait des inconvénients.

Divulgation complète: à l'origine, j'avais préféré l'approche globbing pour sa simplicité, mais au fil des années, j'ai fini par reconnaître que la liste explicite des fichiers est moins sujette aux erreurs pour les grands projets multi-développeurs.

Réponse originale:

Les avantages du globbing sont:

• Il est facile d'ajouter de nouveaux fichiers car ils ne sont répertoriés qu'à un seul endroit: sur le disque. L'absence de globalisation crée une duplication.

• Votre fichier CMakeLists.txt sera plus court. C'est un gros plus si vous avez beaucoup de fichiers. L'absence de globalisation vous fait perdre la logique CMake parmi d'énormes listes de fichiers.

Les avantages de l'utilisation de listes de fichiers codées en dur sont:

• CMake suivra correctement les dépendances d'un nouveau fichier sur le disque - si nous utilisons glob, les fichiers non globalisés la première fois lorsque vous avez exécuté CMake ne seront pas récupérés

• Vous vous assurez que seuls les fichiers souhaités sont ajoutés. Globbing peut ramasser des fichiers parasites dont vous ne voulez pas.

Afin de contourner le premier problème, vous pouvez simplement «toucher» le CMakeLists.txt qui fait le glob, soit en utilisant la commande tactile ou en écrivant le fichier sans modifications. Cela forcera CMake à réexécuter et à récupérer le nouveau fichier.

Pour résoudre le deuxième problème, vous pouvez organiser soigneusement votre code dans des répertoires, ce que vous faites probablement de toute façon. Dans le pire des cas, vous pouvez utiliser la list(REMOVE_ITEM)commande pour nettoyer la liste globale des fichiers:

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

La seule situation réelle où cela peut vous mordre est si vous utilisez quelque chose comme git-bisect pour essayer d'anciennes versions de votre code dans le même répertoire de construction. Dans ce cas, vous devrez peut-être nettoyer et compiler plus que nécessaire pour vous assurer d'obtenir les bons fichiers dans la liste. C'est un cas tellement compliqué, et où vous êtes déjà sur vos gardes, que ce n'est pas vraiment un problème.

La meilleure façon de spécifier les fichiers source dans CMake est de les lister explicitement .

Les créateurs de CMake eux-mêmes conseillent de ne pas utiliser de globbing.

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

(Nous ne recommandons pas d'utiliser GLOB pour collecter une liste de fichiers source à partir de votre arborescence source. Si aucun fichier CMakeLists.txt ne change lorsqu'une source est ajoutée ou supprimée, le système de construction généré ne peut pas savoir quand demander à CMake de se régénérer.)

Bien sûr, vous voudrez peut-être savoir quels sont les inconvénients - continuez à lire!

Quand Globbing échoue:

Le gros inconvénient du globbing est que la création / suppression de fichiers ne met pas automatiquement à jour le système de construction.

Si vous êtes la personne qui ajoute les fichiers, cela peut sembler un compromis acceptable, mais cela pose des problèmes pour les autres personnes qui construisent votre code, ils mettent à jour le projet à partir du contrôle de version, exécutent la version, puis vous contactent, se plaignant que
"la version cassé".

Pour aggraver les choses, l'échec donne généralement une erreur de liaison qui ne donne aucune indication sur la cause du problème et du temps est perdu pour le dépanner.

Dans un projet sur lequel j'ai travaillé, nous avons commencé le globbing, mais nous avons reçu tellement de plaintes lorsque de nouveaux fichiers ont été ajoutés, que c'était une raison suffisante pour lister explicitement les fichiers au lieu de globbing.

Cela rompt également les flux de travail git courants
( git bisectet le basculement entre les branches de fonctionnalités).

Je ne peux donc pas recommander cela, les problèmes que cela pose l'emportent de loin sur la commodité, lorsque quelqu'un ne peut pas créer votre logiciel à cause de cela, il peut perdre beaucoup de temps pour trouver le problème ou simplement abandonner.

Et une autre note, se souvenir de toucher CMakeLists.txtn'est pas toujours suffisant, avec des builds automatisés qui utilisent le globbing, je devais exécuter cmakeavant chaque build car des fichiers pouvaient avoir été ajoutés / supprimés depuis le dernier bâtiment *.

Exceptions à la règle:

Il y a des moments où le globbing est préférable:

• Pour configurer des CMakeLists.txtfichiers pour des projets existants qui n'utilisent pas CMake.
  C'est un moyen rapide d'obtenir toutes les sources référencées (une fois que le système de construction est en cours d'exécution - remplacez le globbing par des listes de fichiers explicites).
• Lorsque CMake n'est pas utilisé comme système de construction principal , si par exemple vous utilisez un projet qui n'utilise pas CMake et que vous souhaitez maintenir votre propre système de construction pour cela.
• Pour toute situation où la liste de fichiers change si souvent qu'il devient impossible de la maintenir. Dans ce cas, cela pourrait être utile, mais vous devez accepter de courir cmakepour générer des fichiers de construction à chaque fois pour obtenir une construction fiable / correcte (ce qui va à l'encontre de l'intention de CMake - la possibilité de séparer la configuration de la construction) .

* Oui, j'aurais pu écrire un code pour comparer l'arborescence des fichiers sur le disque avant et après une mise à jour, mais ce n'est pas une solution de contournement si agréable et quelque chose de mieux laissé au système de construction.

Dans CMake 3.12, les commandes file(GLOB ...)etfile(GLOB_RECURSE ...) ont obtenu une CONFIGURE_DEPENDSoption qui réexécute cmake si la valeur du glob change. Comme c'était le principal inconvénient du globbing pour les fichiers source, il est maintenant possible de le faire:

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

Cependant, certaines personnes recommandent toujours d'éviter le globbing pour les sources. En effet, la documentation déclare:

Nous vous déconseillons d'utiliser GLOB pour collecter une liste de fichiers source à partir de votre arborescence source. ... Le CONFIGURE_DEPENDSdrapeau peut ne pas fonctionner de manière fiable sur tous les générateurs, ou si un nouveau générateur est ajouté à l'avenir qui ne peut pas le prendre en charge, les projets qui l'utilisent seront bloqués. Même si cela CONFIGURE_DEPENDSfonctionne de manière fiable, il y a toujours un coût pour effectuer la vérification à chaque reconstruction.

Personnellement, je considère que les avantages de ne pas avoir à gérer manuellement la liste des fichiers source l'emportent sur les inconvénients possibles. Si vous devez revenir aux fichiers répertoriés manuellement, cela peut être facilement réalisé en imprimant simplement la liste des sources globales et en la recollant.

Vous pouvez glober en toute sécurité (et devrait probablement) au prix d'un fichier supplémentaire pour contenir les dépendances.

Ajoutez des fonctions comme celles-ci quelque part:

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

Et puis allez globbing:

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

Vous êtes toujours en train de faire le tour des dépendances explicites (et de déclencher toutes les constructions automatisées!) Comme avant, seulement c'est dans deux fichiers au lieu d'un.

Le seul changement de procédure intervient après la création d'un nouveau fichier. Si vous ne globez pas le flux de travail consiste à modifier CMakeLists.txt à partir de Visual Studio et à reconstruire, si vous faites glob, vous exécutez cmake explicitement - ou touchez simplement CMakeLists.txt.

Spécifiez chaque fichier individuellement!

J'utilise un CMakeLists.txt conventionnel et un script python pour le mettre à jour. J'exécute le script python manuellement après avoir ajouté des fichiers.

Voir ma réponse ici: https://stackoverflow.com/a/48318388/3929196