0

I'm writing recipe for creating package for rabbitmq-c library. When ENABLE_SSL_SUPPORT option in its CMake script is checked it requires OpenSSL library for its build.

RabbitMQ C client library CMake GUI screen

As it shown on provided screen paths to Debug and Release versions of libeay.lib and ssleay.lib files are required.

In my conanfile.py for rabbitmq-c library I have the following code which describes the dependency.

def requirements(self):
    if self.options.ssl_support:
        self.requires("OpenSSL/1.0.2l@bobeff/stable")

How to get right values from required OpenSSL package to set them in CMake configure options for RabbitMQ-C recipe?

The package OpenSSL/1.0.2l@bobeff/stable can be build with different settings and options. How to choose which to be used when I'm building RabbitMQ-C? For example how to choose whether static or dynamic version of OpenSSL to be used for linking with RabbitMQ-C dll files?

bobeff
  • 3,543
  • 3
  • 34
  • 62
  • 1
    If you mean, how to access the dependencies model, from the consumer recipe (RabbitMQ) you can access it via ``self.deps_cpp_info["OpenSSL"]``. And that object will contain information for ``include_paths``, ``lib_paths``, etc. You can check: http://conanio.readthedocs.io/en/latest/integrations/other.html. Please tell me if this makes sense, and I will elaborate an extended answer – drodri Aug 29 '17 at 14:49
  • @drodri +1 10x It makes perfect sense, but in addition here two different OpenSSL packages are required. One for Debug, and one for Release. Now I'm creating different packages for Debug and Release variants of RabbitMQ-C and because of this I can use the same value, but how to handle this if I was going to create one package for both debug and release versions of RabbitMQ-C? – bobeff Aug 29 '17 at 15:14

1 Answers1

1

You have full access to the dependencies model inside your build() method, so you can access:

def build(self):
    print(self.deps_cpp_info["OpenSSL"].rootpath)
    print(self.deps_cpp_info["OpenSSL"].include_paths)
    print(self.deps_cpp_info["OpenSSL"].lib_paths)
    print(self.deps_cpp_info["OpenSSL"].bin_paths)
    print(self.deps_cpp_info["OpenSSL"].libs)
    print(self.deps_cpp_info["OpenSSL"].defines)
    print(self.deps_cpp_info["OpenSSL"].cflags)
    print(self.deps_cpp_info["OpenSSL"].cppflags)
    print(self.deps_cpp_info["OpenSSL"].sharedlinkflags)
    print(self.deps_cpp_info["OpenSSL"].exelinkflags)

Also if you want to access the aggregated values (for all the dependencies/requirements), you can do:

def build(self):
   print(self.deps_cpp_info.include_paths)
   print(self.deps_cpp_info.lib_paths)
   ...

So, given those values, you can pass them to your build system, in the case of CMake you could do something like:

def build(self):
    cmake = CMake(self)
    # Assuming there is only 1 include path, otherwise, we could join it
    cmake.definitions["SSL_INCLUDE_PATH"] = self.deps_cpp_info["OpenSSL"].include_paths[0]

That will be translated to a cmake command including the -DSSL_INCLUDE_PATH=<path to openssl include> flag.

If you go for multi-configuration packages, you can check (http://docs.conan.io/en/latest/packaging/package_info.html#multi-configuration-packages). They will define debug, release configs, that you can also later use in your model:

def build(self):
    # besides the above values, that will contain data for both configs
    # you can access information specific for each configuration
    print(self.deps_cpp_info["OpenSSL"].debug.rootpath)
    print(self.deps_cpp_info["OpenSSL"].debug.include_paths)
    ...
    print(self.deps_cpp_info["OpenSSL"].release.rootpath)
    print(self.deps_cpp_info["OpenSSL"].release.include_paths)
    ...
drodri
  • 5,157
  • 15
  • 21
  • What about if **OpenSSL** is not multi configuration package but in package recipe which I'm creating I need both Debug and Release versions of **OpenSSL** ? – bobeff Aug 30 '17 at 09:51
  • 1
    That is not possible in the model. Some tricks might be possible, like using the ``cmake_multi`` generator and installing both debug and release dependencies, but that is complex and error prone. So basically, multi-config has to be consistent in the dependency graph, if the package you are building is multi-config, the dependencies have to be multi-config. – drodri Aug 31 '17 at 08:44