0

Objective

I am trying to have CMake find Doxygen on a bunch of different systems and configurations:

  • Online documentation is generated on Ubuntu
  • Local tests and development is done on Macos
  • Doxygen can be installed system-wide, through brew or through conan depending on the use case

Problem

I struggle finding a uniform approach that does not involve a lot of OS-specific operations. I am vaguely tempted to glue together the 3 following approaches, but I am still surprised/concerned/unsure a more elegant solution does not exist.

Sub-solution 1

What I have presently works only for system-wide installations:

find_package(Doxygen
             REQUIRED dot
             OPTIONAL_COMPONENTS mscgen dia)

if(DOXYGEN_FOUND)

  # doxygen settings can be set here, prefixed with "DOXYGEN_"
  # ...

  # this target will only be built if specifically asked to.
  # run "make docs" to create the doxygen documentation
  doxygen_add_docs(
    docs
    ${PROJECT_SOURCE_DIR}
    COMMENT "Generate API-documents."
  )
else (DOXYGEN_FOUND)
  message([WARNING] " Doxygen need to be installed to generate the doxygen documentation")
endif (DOXYGEN_FOUND)

Sub-solution 2:

I am aware I can try to access Conan-installed executable through CONAN_BIN_DIRS_DOXYGEN/doxygen, as explained here

Sub-solution 3:

I am also aware I can try to locate Homebrew installations as described here.

WaterFox
  • 850
  • 6
  • 18
  • 1
    Finding packages in the "build" context, where ``tool_requires`` like Doxygen should be, is a bit challenging, but can be done with ``CMakeDeps``: Using the ``build_context_activated`` (https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmakedeps.html#build-context-activated), can force the creation of doxygen-config.cmake files. And the path to the generated ``doxygen-config.cmake`` file can be also automated with ``CMakeToolchain`` generator – drodri Nov 22 '22 at 23:54
  • Can I use `build_context_activated` with a `conanfile.txt` or have I to use a `conanfile.py` for this? – WaterFox Nov 23 '22 at 01:05
  • 1
    Yes, it is necessary to move to ``conanfile.py``, but it will be very basic, it doesn't need to contain the whole thing, just ``settings``, ``requires`` and the ``generate()`` method – drodri Nov 24 '22 at 09:22
  • 1
    Thank you @drodri! I could do what I wanted thanks to you! I will post the answer based on your comments! – WaterFox Nov 24 '22 at 17:54

1 Answers1

1

Following @drodri comments, the following conan/conanfile.py achieves the desired result for my header-only library:

from conans import ConanFile, CMake
from conan.tools.cmake import CMakeDeps

class MyConan(ConanFile):
    name = "mylib"
    version = "0.1"
    settings = "os", "compiler", "arch", "build_type"
    exports_sources = "include/*", "CMakeLists.txt", "test/*", "cmake/*", "docs/*"
    no_copy_source = True
    generators = "cmake", "CMakeToolchain", "CMakeDeps"
    requires = "boost/[>=1.78.0]", "gdal/[>=3.4.3]"
    tool_requires = "cmake/3.24.2", "doxygen/1.9.4"

    def generate(self):
        cmake = CMakeDeps(self)
        # generate the config files for the tool require
        cmake.build_context_activated = ["doxygen/1.9.4"]
        cmake.generate()

    def build(self): # this is not building a library, just tests
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        cmake.test(output_on_failure=True)

    def package(self):
        self.copy("*.h")

    def package_id(self):
        self.info.clear()

It can be called with conan install conan/conanfile.py --build=missing --install-folder=build -pr:b=conan/profiles/clang_13 -pr:h=conan/profiles/clang_13

WaterFox
  • 850
  • 6
  • 18