Should this be using CDT Dependencies?

[paxsonsa]

Hey there,

I was look at this recipe and it appears that it relies on OpenGL being installed on the local machine. Do we think this should be more isolated and use the cdt functionality available?

Cheers!

[dschreij]

I'm the maintainer of this feedstock, although I think I'm the wrong person to ask. I have no idea what the policies are regarding when to use CDT or not. @conda-forge/core, care to shine your light on this?

[scopatz]

The basic heirarchy for dependencies is, in order of preference is,

• Make or use a conda-forge package for the dep
• Use a defaults package for a dep
• Use a CDT for a dep
• Use a yum_requirements for a dep
• Silently require the package to exist

[paxsonsa]

I am just getting up to speed on the whole CDTs and conda isolation. @scopatz that is really useful information.

Let me take a stab at an example and hopefully @conda-forge/core will be able to validate if I am mixing something up.

[scopatz]

Yeah, it should probably be in the docs :)

[scopatz]

Added in conda-forge/conda-forge.github.io#690

[paxsonsa]

So one one of the major first things for higher isolation is build and relying on libGL which conda-forge does not yet have (or I can't find it)

I did a test on my end with Centos7/6 to see what I would need to do to build with mostly cdts and a cmake toolchain file. I am not sure if that is the best approach and frankly, I still don't understand the the way CDTs operate with a package. One way I got it building for linux was like so:

meta.yaml

{% set name = "glew" %}
{% set version = "2.0.0" %}
{% set sha256 = "cc88d2f70a185185eb050eb13789f498425fcd58230bfd65da496b8008f046f2" %}
{% set dev_url = "https://github.com/nigels-com/glew" %}

package:
  name: {{ name|lower }}
  version: {{ version }}

source:
  fn: {{ name }}-{{ version }}.zip
  url: {{ dev_url }}/releases/download/{{ name }}-{{ version }}/{{ name }}-{{ version }}.zip
  sha256: {{ sha256 }}

build:
  number: 1

requirements:
  build:
    - {{ compiler("c") }}
    - {{ compiler("cxx") }}
    - cmake
    - pkg-config                         # [linux]
    - {{ cdt('xorg-x11-proto-devel') }}  # [linux]
    - {{ cdt('libx11-devel') }}          # [linux]
    - {{ cdt('libxcb') }}                # [linux]
    - {{ cdt('libXfixes') }}             # [linux]
    - {{ cdt('libXxf86vm') }}            # [linux]
    - {{ cdt('libxext-devel') }}         # [linux]
    - {{ cdt('libxrender-devel') }}      # [linux]
    - {{ cdt('mesa-libgl-devel') }}      # [linux]
    - {{ cdt('mesa-dri-drivers') }}      # [linux]
    - {{ cdt('libselinux') }}            # [linux]
    - {{ cdt('libXdamage') }}            # [linux]
    - {{ cdt('libXau') }}                # [linux]

  run:
    - {{ cdt('libx11') }}                # [linux]
    - {{ cdt('libxcb') }}                # [linux]
    - {{ cdt('libXfixes') }}             # [linux]
    - {{ cdt('libXxf86vm') }}            # [linux]
    - {{ cdt('libxext') }}               # [linux]
    - {{ cdt('libxrender') }}            # [linux]
    - {{ cdt('mesa-libgl') }}            # [linux]
    - {{ cdt('mesa-dri-drivers') }}      # [linux]
    - {{ cdt('libselinux') }}            # [linux]
    - {{ cdt('libXdamage') }}            # [linux]
    - {{ cdt('libXau') }}                # [linux]

test:
  requires:
    - {{ compiler("c") }}
    - {{ compiler("cxx") }}
    - cmake
  commands:
    - test -f $PREFIX/include/GL/glew.h  # [unix]

Then adding a cmake file like so:
linux.cmake

# this one is important
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_PLATFORM Linux)
#this one not so much
# set(CMAKE_SYSTEM_VERSION 1)

# specify the cross compiler
set(CMAKE_C_COMPILER $ENV{CC})

# where is the target environment
set(CMAKE_FIND_ROOT_PATH "$ENV{PREFIX}" "$ENV{BUILD}/$ENV{HOST}/sysroot" "$ENV{BUILD_PREFIX}/$ENV{HOST}/sysroot")

# search for programs in the build host directories
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Then the build scripts cmake call contains this:

cmake -DCMAKE_INSTALL_PREFIX:PATH="${PREFIX}" \
      -DCMAKE_INSTALL_LIBDIR="lib" \
      -DCMAKE_TOOLCHAIN_FILE="${RECIPE_DIR}/linux.cmake" \
      ./cmake

I am not sure if this is even what we need as when the run installation it all the libGL libs are installed in the sys root of the environment and I am not sure how that is used.

Hopefully someone can enlighten this/us. I also think this avoids using conda-forge packages which it should probably NOT do.

[jakirkham]

Thanks for adding that info here, @scopatz. Agree we should get it in the docs. Raised a couple questions in that PR.

[jakirkham]

Thanks for giving this a go, @paxsonsa.

As you note we don't have something providing libgl (or at least I also don't know where to look for this :). This starts getting closer to the system level (i.e. drivers become involved). So it's less clear how much of this we can package safely and how portable it is. Do you have thoughts on this?

However for X11 packages, we have a pretty good story in conda-forge and we are starting to make increasing use of these in conda-forge. Plus we have some pretty knowledgeable maintainers supporting that stack. In particular qt already uses them heavily. freeglut soon will. Not too mention numerous other downstream packages have been picking these up. Nearly all of the conda-forge X11 packages have an xorg-* prefix to their name (e.g. xorg-libx11). So they should be pretty easy to find. Though a few do differ (e.g. libxcb ). Please ask if you are not sure.

There are a couple X11 packages we may be missing. Some of which we have learned by starting down this migration path. Have documented a few of them in issue ( conda-forge/staged-recipes#7453 ). Please add more if you see them.

Edit: As a follow-up on the libGL.so point, it should be installed with mesalib I believe, but it is not currently. ( conda-forge/mesalib-feedstock#16 )

[jakirkham]

Going to close as this has been addressed in PR ( #8 ), which was recently merged. However feel free to ask other questions should they arise.