CONAN 2 Tests

Das Drama mit CONAN ist oft, dass die Entwicklung in unterschiedlichen Kontexten läuft. Und ein conan create führt Builds und Tests manchmal ganz anders aus, als ein cmake build nach einem conan install.

Auf zur Analyse!

conan build und conan create laden alle Abhängigkeiten und fügen die notewendigen Pfade in die PATH und LD_LIBRARY_PATH Umgebungsvariablen ein, wenn Prozesse wie cmake gestartet werden.
Laufen dann Tests, erben die Test-Prozesse die Umgebung und alles läuft problemlos.

Bei der Entwicklung nutzen wir aber häufig conan install und conan source und danach starten wir cmake oder eine IDE (wie VSCode) manuel, wo diese Umgebung fehlt.
Die Builds laufen dann, aber Tests können die notwendigen Bibliotheken zur Laufzeit nicht finden und schlagen fehl.

Hinweis: Kleine Projekte haben das Problem nicht, denn wenn alles lokal gebaut wird, sind die korrekten Pfade des Build-Prozesses in den Binaries selbst gespeichert. Doch wenn per CI fertige Komponenten auf den eigenen Conan-Remote hochgeladen wurden und das eigene Projekt diese herunterlädt, dann passt das Setup nicht mehr zusammen und PATH bzw. LD_LIBRARY_PATH werden zwingend erforderlich.

CONAN virtual run environment

Die Standard Lösung lautet: Erzeuge ein Run-Environment und starte die IDE oder den Build-Prozess aus diesem heraus.
Conan legt herfür conanrun Scripts an, die man einfach vor dem Build oder der IDE starten muss:

Windows: CMake und Visual Code mit CONAN run environment

cd myproject
conan install .
build\generators\conanrun.bat
cmake --preset conan-debug
cmake --build --preset conan-debug
code .
build\generators\deactivate_conanrun.bat

Linux: CMake und Visual Code mit CONAN run environment

cd myproject
conan install .
source build/generators/conanrun.sh
cmake --preset conan-debug
cmake --build --preset conan-debug
code .
source build/generators/deactivate_conanrun.sh

CONAN und CMake generieren Environment und Launch Dateien

Das wiederholte manuelle Aufrufen von Scripts wird extrem mühsam, wenn man zwischen vielen Conan-Projekten hin und herwechseln muss.

Ich wollte daher eine Variante haben, in der jedes Projekt mit wenigen Zeilen in VSCode geladen werden kann, und zwar mit:

cd myproject
conan install .
code .

Um jetzt das notwendige Environment zu “konservieren”, damit man es beim Debuggen benutzen kann, erzeuge ich in der Conan generate() Methode eine .env Datei im Build-Verzeichnis.
Da Windows und Linux etwas unterschiedlich sind, fällt der Code etwas größer aus und sieht etwa so aus:

 # conanfile.py
 
 class myProject_ConanFile(ConanFile):
   ...
   def create_env_file(self, env_file_path: str):
     is_windows = self.settings.os == "Windows"
     path_name = "PATH"
     path_var = "%PATH%" if is_windows or "$PATH"
     lib_name = "LIB" if is_windows or "LD_LIBRARY_PATH"
    lib_var = "%LIB%" if is_windows or "$LD_LIBRARY_PATH"

    env_bin_paths = []
    env_lib_paths = []

    ## add conan dependencies to PATH and LIBS array
    for dep in self.dependencies.values():
      env_bin_paths.append(str(bin)) for bin in dep.cpp_info.bindirs
      env_lib_paths.append(str(lib)) for lib in dep.cpp_info.libdirs

    ## add current PATH entries
    env_bin_paths.extend(os.getenv(path_name, "").split(os.pathsep))
    env_lib_paths.extend(os.getenv(lib_name, "").split(os.pathsep))

    ## remove empty entries
    env_bin_paths = [e for e in env_bin_paths if e]
    env_lib_paths = [e for e in env_lib_paths if e]

    with open(env_file_path, "w") as f:
      path_text = os.pathsep.join(env_bin_paths)
      f.write("{}={}\n".format(path_name, path_text))
      lib_text = os.pathsep.join(env_lib_paths)
      f.write("{}={}\n".format(lib_name, lib_text))

  def generate(self):
    tc = CMakeToolchain(self)
    tc.generate()

    cmakedeps = CMakeDeps(self)
    cmakedeps.generate()

    if self.settings.build_type == "Debug":
      env_file_path = os.path.join(self.build_folder, ".env")
      self.create_env_file(env_file_path)
  ...

Anschließend wird in den Launch-Jobs für VSCode die .env Datei referenziert und somit startet jede Debug-Target-Start bzw. jeder Debug-CTest-Start mit den Pfaden, die Conan in seinen Dependencies bereits aufgelöst hat.

 // .vscode/launch.json
 {
   "version": "0.2.0",
   "configurations": [
     {
       "name": "(gdb) CMake Target",
       "type": "cppdbg",
       "MIMode": "gdb",
       "request": "launch",
      "program": "${command:cmake.launchTargetPath}",
      "args": [],
      "cwd": "${command:cmake.buildDirectory}",
      "envFile": "${command:cmake.buildDirectory}/.env"
    },
    {
      "name": "(gdb) CTest Launch",
      "type": "cppdbg",
      "MIMode": "gdb",
      "request": "launch",
      "program": "${cmake.testProgram}",
      "args": [ "${cmake.testArgs}" ],
      "cwd": "${cmake.testWorkingDirectory}",
      "envFile": "${command:cmake.buildDirectory}/.env"
    },
    {
      "name": "(msvc) CMake Target",
      "type": "cppvsdbg",
      "request": "launch",
      "program": "${command:cmake.launchTargetPath}",
      "args": [],
      "cwd": "${command:cmake.buildDirectory}",
      "envFile": "${command:cmake.buildDirectory}/.env"
    },
    {
      "name": "(msvc) CTest Launch",
      "type": "cppvsdbg",
      "request": "launch",
      "program": "${cmake.testProgram}",
      "args": [ "${cmake.testArgs}" ],
      "cwd": "${cmake.testWorkingDirectory}",
      "envFile": "${command:cmake.buildDirectory}/.env"
    }
  ]
}

Wer CTest direkt (also ohne VS-Code Debugger) startet, hat das gleiche Problem, doch hier kann man den Fix in CMake integrieren.
Die .env Datei wird gelesen und ihr Inhalt als Array dem CTest-Property ENVIRONMENT zugeordnet.

 set(test_name "my_test")
 set(test_command "${PROJECT_NAME}")
 set(test_args)
 
 add_test(NAME ${test_name} COMMAND "${test_command}" ${test_args})
 
 if(EXISTS "${CMAKE_BINARY_DIR}/.env")
   file(READ "${CMAKE_BINARY_DIR}/.env" envfile_content)
 
  # The Windows "path1;path2" format needs to be escaped 
  # to avoid conflicts with cmake's array ";" separation
  string(REPLACE "\r" "" envfile_content "${envfile_content}")
  string(REPLACE ";" "\\;" envfile_content "${envfile_content}")
  string(REPLACE "\n" ";" envfile_entries "${envfile_content}")

  set_property(TEST ${test_name} 
    PROPERTY ENVIRONMENT "${envfile_entries}")
endif()

Eine andere Option wäre dann noch Conan-Variablen in CMake zu nutzen, was ich aber nicht so gerne mache, schließlich soll CMake nicht von Conan abhängen.
Trotzdem helfen folgende Zeilen manchmal sehr:

foreach(item ${CONAN_RUNTIME_LIB_DIRS})
  list(APPEND path_patches "PATH=path_list_append:${item}")
endforeach()

set_property(TEST ${test_name} 
  PROPERTY ENVIRONMENT_MODIFICATION ${path_patches})

Fazit

Ein Problem, viele Möglichkeiten, und unnötig viel Komplexität.

Diese Beispiele sind das Ergebnis einer Monate-langen Herumspielerei. Wir haben in der Firma 100+ Conan Projekte, die alle über eine gemeinsame Conan- und CMake- Bibliothek zusammenhängen.

So kann man sicherstellen, dass alle Projekte auf alle Fälle vorbereitet sind. Im Einzelfall sind diese “Patches” oft nicht notwendig, doch wenn viele Ebenen aufeinandertreffen, gibt es immer wieder mal Pfad-Probleme, die so zumindest umgangen werden können.

Ein Problem ist vor allem, dass jeder Developer anders arbeitet. Einer startet alles von der Konsole aus, einer nutzt Visual Studio und andere nehmen VSCode. Die Platformen sind Windows, Liunx, 32-bit und 64-bit für Debug und Release.

Es war echt mühsam immer wieder feststellen zu müssen, dass es genau in einer Variante hakte, während alle anderen liefen.

Aber das ist nunmal unser Job: Nämlich alles zu meistern.