CI failure on Windows with conda dependencies due to glm

[S-Dafarra]

Here the workflow failure:
https://github.com/ami-iit/yarp-device-openxrheadset/actions/runs/4878414507/jobs/8706280938

The error is:

LINK : fatal error LNK1181: cannot open input file 'glm.lib' [D:\a\yarp-device-openxrheadset\yarp-device-openxrheadset\build\_deps\glfont-build\GLFont.vcxproj]

Apparently, there has been a recent update by @traversaro: conda-forge/glm-feedstock#15

@traversaro any suggestion?

[traversaro]

Probably something is broken in glm CMake files upstream and the recipe did not have appropriate tests. This also broke the superbuild, I will check but I fear I only can this late afternoon, in the meanwhile a quick workaround is to install an older version of glm.

[traversaro]

Ok, the problem is the following:

• glm 0.9.9.4 can be used via the glm imported target that is found with find_package(glm REQUIRED) (this support was added in https://github.com/g-truc/glm/pull/324/files and removed in glm 0.9.9.6 in g-truc/glm@5f352ec)
• glm 0.9.9.8 (as patched in conda-forge) can be instead be used via the glm::glm imported target that is found with find_package(glm REQUIRED) (that was added in the future glm 0.9.9.9 in Create an install and package targets in cmake tree g-truc/glm#1054)

So, if we want to be compatible with both versions of glm, we need to link either glm or glm::glm depending on which one is available.

[traversaro]

By the way, Ubuntu 22.04 has the latest glm 0.9.9.8, but uses the glm target due to a local patch: https://sources.debian.org/patches/glm/0.9.9.8%2Bds-6/cmake-install-target.patch/, that however adds a behaviour different from upstream g-truc/glm#1054 .

[traversaro]

I was wondering: but why conda-forge/Linux works? The point is this projects calls find_package(GLM) . As YCM is used, this calls https://github.com/robotology/ycm/blob/v0.15.1/find-modules/FindGLM.cmake, that inside calls find_package(GLM CONFIG QUIET) . This on Ubuntu does not find anything (and fallback to define a glm target), while in Windows it finds glmConfig.cmake as the filesystem is not case sensitive. For the future, I think it make sense to start using find_package(glm) and stop relying on YCM to find this.

[traversaro]

Fixed by:

• FindGLM: define both glm and glm::glm imported targets robotology/ycm-cmake-modules#430
• FindGLM: Fix check for non-existing variable GLM_CONFIG robotology/ycm-cmake-modules#431
• ENH: update package version conda-forge/ycm-cmake-modules-feedstock#16
• Automatic update of latest releases versions robotology/robotology-superbuild#1402

[S-Dafarra]

Thanks a lot! I guess I need to wait for ycm-cmake-modules v0.15.2 to be available then. I tried to rerun it a few minutes ago, but it still downloads v0.15.1: https://github.com/ami-iit/yarp-device-openxrheadset/actions/runs/4889262237/jobs/8731003883

[traversaro]

Fixed, see https://github.com/ami-iit/yarp-device-openxrheadset/actions/runs/4889262237/jobs/8735244636 .