Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Conda CI on Linux avoiding to use the defaults channel by installing Mambaforge #840

Merged
merged 2 commits into from
Aug 2, 2021

Conversation

traversaro
Copy link
Member

@traversaro traversaro commented Jul 30, 2021

The CI has been using the defaults channel (even if this was not wanted) for a long time, see conda-incubator/setup-miniconda#186 and #669 . However, since yesterday this created a compilation error:

2021-07-30T02:25:20.1711320Z /usr/share/miniconda/envs/test/x86_64-conda-linux-gnu/include/c++/9.3.0/ctime:80:11: error: '::timespec_get' has not been declared
2021-07-30T02:25:20.1712202Z    80 |   using ::timespec_get;
2021-07-30T02:25:20.1712597Z       |           ^~~~~~~~~~~~

For this reason, better to cleanup the use of conda channels in the CI, making sure that we don't use defaults at all, by using Mambaforge as base installer.

Similar to robotology/robometry#141 .
Fix #669 .

@traversaro traversaro requested a review from Nicogene July 30, 2021 14:16
@traversaro traversaro changed the title Fix Conda CI on Linux avoiding to use the defaults channel Fix Conda CI on Linux avoiding to use the defaults channel by installing Mambaforge Jul 30, 2021
@traversaro
Copy link
Member Author

The macOS CI failures are unrelated and due to #841, please ignore them.

@traversaro traversaro merged commit 14695f5 into master Aug 2, 2021
@traversaro traversaro deleted the fix-conda-ci branch August 2, 2021 12:12
traversaro added a commit to robotology/idyntree-yarp-tools that referenced this pull request Jan 12, 2023
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
* gazebosim/gazebo-classic#3287
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make sure that conda based CI does not accidentally use defaults channel
2 participants