You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A common failure point in robostack is that we have conda-forge C++ libraries packages that do not have an output that can be installed to ensure that all the dependencies required to build a downstream C++ project. This is not an issue if a C++ package already include its headers and only use as public dependencies in its headers conda-forge libraries that also ship their headers in the main package, but as soon a dependency uses in its headers a dependency that ships its headers in a separate *-devel package, we need to have a *-devel output also for that package, or it needs to adds the *-devel package to its run dependencies, but some mantainer may be against this as it goes around the point of splitting *-devel packages.
Problematic packages:
qt-main : Depends on libgl-devel, but at runtime it only requires libgl
vtk : Depends on qt-main, i.e. inheriting the libgl-devel problem
pcl: Depends on qt-main, i.e. inheriting the libgl-devel problem
libspnav : Depends on xorg-xorgproto, as @Tobias-Fischer is the maintainer and the package is quite simple probably we can avoid the libspnav-devel output and just add xorg-xorgproto as run dependency.
The text was updated successfully, but these errors were encountered:
Sorry, I guess the context is not clear, as I forgot to press submit on this message: RoboStack/ros-humble#229 (comment) . Another important piece of context is that the issue is definitely not robostack-specific but rather conda-forge, I just opened the issue here as I got a clear idea regarding that while working on the ros humble rebuild and to avoid forgetting about it.
Can't we just add libgl-devel to the mapping of e.g. pcl etc. in the robostack.yaml?
Sure, that is what we have done until now (also as the situation was much more complex, as there were cdt involved, so we had REQUIRE_GL and REQUIRE_OPENGL).
We can add libgl-devel to each package that inclue Qt headers in its public headers as we did until now, but I see the following downside:
libgl-devel is required (and available) only on Linux, so we would need to split in platform specific sections all the affected dependencies (that is the main reason for now I kept REQUIRE_GL and REQUIRE_OPENGL in linux-64 - rebuild Christmas 2024 - switch to rattler-build ros-humble#229 for now)
The problem is not robostack-specific, so personally I think I have at least other ~30 places (superbuild, individual packages CI, conda environments, conda-forge recipes) in which I need to manually add libgl-devel as I depend on qt-main, vtk or pcl. If there was a qt-main-devel, I could just add it and the semantics of what I am trying to do would be clear.
Anyhow, I realize this is mostly OT here, so if you prefer I can close the issue here.
A common failure point in robostack is that we have conda-forge C++ libraries packages that do not have an output that can be installed to ensure that all the dependencies required to build a downstream C++ project. This is not an issue if a C++ package already include its headers and only use as public dependencies in its headers conda-forge libraries that also ship their headers in the main package, but as soon a dependency uses in its headers a dependency that ships its headers in a separate
*-devel
package, we need to have a*-devel
output also for that package, or it needs to adds the*-devel
package to its run dependencies, but some mantainer may be against this as it goes around the point of splitting*-devel
packages.Problematic packages:
qt-main
: Depends onlibgl-devel
, but at runtime it only requireslibgl
vtk
: Depends on qt-main, i.e. inheriting thelibgl-devel
problempcl
: Depends on qt-main, i.e. inheriting thelibgl-devel
problemlibspnav
: Depends onxorg-xorgproto
, as @Tobias-Fischer is the maintainer and the package is quite simple probably we can avoid thelibspnav-devel
output and just addxorg-xorgproto
as run dependency.The text was updated successfully, but these errors were encountered: