Jeu de Variables avec PARENT_SCOPE sont vides dans l'enfant. Pourquoi?

Envisager minimales suivantes par exemple:

.
├── bar
│   └── CMakeLists.txt
└── CMakeLists.txt

où ./CMakeLists.txt est

project( foo )
cmake_minimum_required( VERSION 2.8 )

set( FOO "Exists in both, parent AND in child scope." )

add_subdirectory( bar )
message( STATUS "Variable BAR in ./    = ${BAR}" )
message( STATUS "Variable FOO in ./    = ${FOO}" )

et ./bar/CMakeLists.txt est

set( BAR "Exists in parent scope only." PARENT_SCOPE )
message( STATUS "Variable BAR in ./bar/= ${BAR}" )

La partie pertinente de la sortie de cmake est-ce:

...
-- Variable BAR in ./bar/=
-- Variable FOO in ./bar/= Exists in both, parent AND in child scope.
-- Variable BAR in ./    = Exists in parent scope only.
-- Variable FOO in ./    = Exists in both, parent AND in child scope.
...

Puisque la variable BAR est placé dans la portée parent je m'attends à ce qu'elle soit disponible dans le courant de l'enfant de la portée de l' (et dans ceux qui suivent), tout comme la variable FOO, qui est définie de la portée parent pour commencer. Mais comme on peut le voir dans les lignes ci-dessus le
variable BAR est vide dans ./bar/CMakeLists.txt, qui me conduisent à
les questions suivantes:

Pourquoi le modifié parent pas immédiatement accessible à l'enfant
portée, ./bar/? Cela peut-il être atténués? Si oui, comment? Et si non, qu'est ce qu'un
travail autour? Ou suis-je complètement à côté de quelque chose d'évident?

Contexte: mon projet est constitué de plusieurs fichiers exécutables et les bibliothèques. Pour un
bibliothèque, par exemple bar, j'aimerais définir une variable bar_INCLUDE_DIR qui
est ajouté à inclure les chemins de tout en fonction de l'exécutable, c'est à dire target_include_directories( my_target PUBLIC bar_INCLUDE_DIR ).

InformationsquelleAutor nils | 2015-04-27
  1. 4

    Contexte: mon projet est constitué de plusieurs fichiers exécutables et les bibliothèques. Pour une bibliothèque, par exemple, un bar, j'aimerais définir une variable bar_INCLUDE_DIR qui est ajouté à inclure les chemins de toute fonction exécutable.

    Il est beaucoup mieux pour ce faire que de définir des variables dans la portée parent. CMake permet une cible pour spécifier inclure des répertoires, des symboles de préprocesseur etc. que selon les objectifs peuvent utiliser. Dans votre cas, vous pouvez utiliser target_include_directories.

    Par exemple:

    target_include_directories(my_target PUBLIC my_inc_dir)
    • En fait, c'est ce que je l'aide. Mais depuis my_target est dans un frère de portée par rapport à une bibliothèque bar, j'utilise le détour par le parent à l'avant de l'emplacement du répertoire include.
    • Vous n'avez pas besoin de variables pour transmettre cette information. Tout ce que vous devez faire est d'appliquer target_include_directories sur la bibliothèque et tous les autres qui l'utilisent seront automatiquement obtenir les répertoires appropriés dans leur chemin.
    • Aaah, maintenant je comprends ce que tu veux dire. C'est beaucoup mieux, en effet. Merci pour votre persévérance!
    • Le mise à jour de la documentation dit Note that it is not advisable to populate the INSTALL_INTERFACE of the INTERFACE_INCLUDE_DIRECTORIES of a target with paths for dependencies. That would hard-code into installed packages the include directory paths for dependencies as found on the machine the package was made on. Donc, vous devriez certainement spécifier BUILD_INTERFACE
    • Bon point!
    • Si vous parvenez à le faire fonctionner pour votre exemple de projet merci de poster le code quelque part: j'ai essayé dans un projet que j'ai et ça ne marcherait pas, mais il peut certainement être parce qu'il est compliqué de projection et il ya plusieurs autres choses que mon CMake fichiers sont en train de faire.

    InformationsquelleAutor Lindydancer
  2. 7

    Je ne vois pas tout ce qui n'est pas compatible avec la ENSEMBLE de commande de la documentation

    Si PARENT_SCOPE est présent, la variable sera définie dans le champ d'application au-dessus de la portée actuelle. Chaque nouveau répertoire ou de la fonction crée un nouveau champ d'application. Cette commande permet de définir la valeur d'une variable dans le répertoire parent ou de l'appel de fonction (selon ce qui est applicable à l'espèce).

    ./bar/CMakeLists.txt

    set( BAR "This is bar." PARENT_SCOPE ) #<-- Variable is set only in the PARENT scope
message( STATUS "Variable BAR in ./bar/= ${BAR}" ) #<--- Still undefined/empty

    Vous pouvez toujours le faire:

    set( BAR "This is bar." ) #<-- set in this scope
set( BAR ${BAR} PARENT_SCOPE ) #<-- set in the parent scope too

    Grep pour PARENT_SCOPE dans la livraison des modules de votre installation, par exemple FindGTK2 

    if(GTK2_${_var}_FOUND)
   set(GTK2_LIBRARIES ${GTK2_LIBRARIES} ${GTK2_${_var}_LIBRARY})
   set(GTK2_LIBRARIES ${GTK2_LIBRARIES} PARENT_SCOPE)
endif()
    • Eh bien, pensez à une variable FOO qui est défini dans la portée parent pour commencer, ensuite cette variable est également disponible dans l'enfant de la portée (voir la mise à jour, par exemple). Alors pourquoi ne pas BAR être disponible à l'enfant si les deux vivent dans le même (parent) portée? J'attendrais la documentation oublier de mentionner un tel comportement.
    • Cela pourrait être possible vu comme un effet secondaire
    InformationsquelleAutor Peter
  3. 7

    Peter a bien expliqué la raison de ce comportement.

    Une solution de contournement, j'ai l'habitude d'utiliser dans ce cas est de définir une variable mise en cache, qui sera visible partout:

    set(BAR "Visible everywhere"
        CACHE INTERNAL "" FORCE
)

    INTERNAL est de le rendre non visible de cmake-gui. FORCE est de faire en sorte qu'il soit mis à jour si vous modifiez quelque chose, par exemple dans votre structure de dossier. La chaîne vide est une chaîne de description, que vous pouvez remplir si vous croyez que c'est nécessaire.

    Noter, cependant, que la bonne approche est d'attacher des propriétés à des objectifs chaque fois que possible, comme l'utilisation de target_incude_directories, et de les propager à d'autres objectifs dans le cadre de dépendances.

    • Merci pour le CACHE option. Toutefois, l'avoir compris ce que @Lindydancer voulait dire, j'ai tendance à préférer cette méthode.
    • Ce n'est certainement pas la bonne approche, car il peut affecter chaque fonction et le contexte de façon aléatoire. CACHE va effacer la valeur d'origine, FORCE va se substituer à l'correspondant -D option. Au lieu d'utiliser le cache, vous devez envisager de définir une valeur dans les deux contextes, un parent et un enfant au lieu de everythere. Sinon, ne pas utiliser des variables et utiliser à la place des propriétés attachées à une cible ou quelque chose d'autre.
    • La meilleure approche est en effet d'utiliser autant que possible les propriétés associées à une cible, et de les propager tout en spécifiant les dépendances. Cette réponse répondre au besoin (si il en existe un, j'ai dit que c'est en effet une solution de contournement) pour définir une variable globale visible partout, dans des répertoires frère en particulier.
    InformationsquelleAutor Antonio
  4. 0

    Chaque variable dans le cmake a son propre champ d'application de sorte qu'il est dangereux d'utiliser le cas où une variable automatiquement se propage dans un contexte enfant, car il peut interférer avec elle à partir d'un parent!

    Mais vous pouvez définir simplement une autre variable d'un enfant à portée de le tester plus tard au lieu de relire un parent d'un:

    ./bar/CMakeLists.txt:

    set( BAR "Exists in parent scope only." PARENT_SCOPE )
set( _somerandomid_BAR "Exists in child scope only.")
message( STATUS "Variable BAR in ./bar/= ${_somerandomid_BAR}" )

    Maintenant, si vous avez des boucles dans votre code, vous pouvez tester les deux variables:

    foreach(...)
  ...
  # read a variable token name and token value, for example, from a configuration file
  set(my_var_name_token ...)
  set(my_var_value_token ...)
  ...
  # parse a variable name and value tokens into a real name and value
  set(my_var_name ...)
  set(my_var_value ...)
  ...
  if (DEFINED ${my_var_name})
    if (DEFINED local_${my_var_name})
      message("has been defined before and was resetted");
    else()
      message("has been defined before and was not resetted");
    endif()
  else()
    if (DEFINED local_${my_var_name})
      message("has not been defined before and was setted");
    else()
      message("has not been defined before and was not touched");
    endif()
  endif()
  ...
  # sets parsed name and value into cmake context
  set(${my_var_name} "..." PARENT_SCOPE)

  # Do save all values has been setting from this function to differently compare and 
  # validate them versus already existed before:
  # 1. If has been set before, then must be set to the same value, otherwise - error
  # 2. If has not been set before, then should set only once, otherwise - ignore new 
  # value (a constant variable behaviour)
  set(local_${my_var_name} "...")
  ...
endforeach()
    InformationsquelleAutor Andry