FindGraphviz: Add Graphviz_DEFINITIONS to define GVDLL and release 0.14.2 #414
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
traversaro
changed the title
This was referenced Jun 10, 2022
S-Dafarra
approved these changes
Jun 10, 2022
8 tasks
8 tasks
traversaro
added a commit
to gazebosim/gazebo-classic
that referenced
this pull request
Jan 27, 2023
…supporting graphviz >= 3 on Windows (#3287) The fix is composed by two unrelated changes ### [Fix conda-forge GitHub Action CI by using mambaforge directly](eea77c2) Currently the CI is failing on Linux and Windows with a weird conflict error. This is due to the fact that we are install mamba (from the conda-forge channel) on the top of miniconda3 (that by default install all the packages from the defaults channel). To make an analogy in apt world, this is like installing Debian, and then trying to install packages from the Ubuntu repo: something can go wrong. To solve this problem, we install [mambaforge](https://github.com/conda-forge/miniforge) (a installer like miniconda3 but already using conda-forge packages) directly, so we always and only use packages from the conda-forge channel. Similar to: * robotology/robotology-superbuild#840 * robotology/robometry#141 * robotology/yarp-devices-ros2#44 ### [Add support to use graphviz >= 3 on Windows](15435b1) Since graphviz 3, any downstream library that on Windows links against a graphviz shared library needs to define the `GVDLL` preprocessor definition (see https://gitlab.com/graphviz/graphviz/-/blob/3.0.0/CHANGELOG.md#changed). To deal with this, this PR adds the `GVDLL` definition for `gazebo_gui` when on Windows (on graphviz < 3 defining this definition will be harmless). As that prepocessor definition should not be set when linking static graphviz, and given that we can't detect in `FindGraphviz` if the linked graphviz is static or not, an ad-hoc CMake variable `GAZEBO_FINDGRAPHVIZ_USE_STATIC_GRAPHVIZ` is introduced in the case this definition needs to be disabled. Similar to robotology/ycm-cmake-modules#414 .
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since graphviz 3, any downstream library that on Windows links against a graphviz shared library needs to define the
GVDLLpreprocessor definition (see https://gitlab.com/graphviz/graphviz/-/blob/3.0.0/CHANGELOG.md#changed).To deal with this, this PR adds the
Graphviz_DEFINITIONSoutput variable to theFindGraphvizmodule, and populates withGVDLLwhen on Windows (on graphviz < 3 defining this definition will be harmless). As that prepocessor definition should not be set when linking static graphviz, and given that we can't detect inFindGraphvizif the linked graphviz is static or not, an ad-hoc CMake variableYCM_FINDGRAPHVIZ_USE_STATIC_GRAPHVIZis introduced in the case this definition needs to be disabled.Partial fix for robotology/robotology-superbuild#1166 and robotology/robotology-superbuild#1152 .