Conan: cmake_multi .cmake files containing duplicated paths [question]

[cj-williams]

To help us debug your issue please explain:

• [X] I've read the CONTRIBUTING guide.
• [X] I've specified the Conan version, operating system version and any tool that can be relevant.
• [X] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

Hi I'm currently using Conan 1.2.2 on Windows 7 (x86_64) with CMake 3.8, but this is also reproducible on a Linux system

The use-case is as follows:

There is a Conan package that has both debug and release libs in it i.e.:

from conans import ConanFile, CMake, tools
class HelloConan(ConanFile):
    name = "Hello"
    version = "0.1"
    settings = "os", "compiler", "arch"
    options = {"shared": [True, False]}
    default_options = "shared=False"
    generators = "cmake"
    def configure(self):
        # it is also necessary to remove the VS runtime
        if self.settings.compiler == "Visual Studio":
            del self.settings.compiler.runtime

    ...

    def package_info(self):
        self.cpp_info.release.libs = ["hello"]
        self.cpp_info.debug.libs = ["hello_D"]

If the package 'consumer' uses the cmake_multi generator, ie:

from conans import ConanFile, CMake
class MyConan(ConanFile):
    settings = "os", "compiler", "build_type" "arch"
    generators = "cmake_multi"

    def requirements(self):
        self.requires("Hello/0.1@test/package")

when running conan install then the conanbuildinfo_debug.cmake and conanbuildinfo_release.cmake file defines the same lib directory twice:

 set(CONAN_LIB_DIRS_HELLO_RELEASE "/home/user/.conan/data/Hello/0.1/test/package/package/d345389f5a480bc5618954ee6ceb6c423427f6b6/lib"
                    "/home/user/.conan/data/Hello/0.1/test/package/package/d345389f5a480bc5618954ee6ceb6c423427f6b6/lib")

The same package is being used for both configurations, as I would expect, but I wouldn't expect the variable to contain the duplication.

I'm not sure if this is a bug or intended behaviour?

Thanks!

[memsharded]

Yes it seems this is unintended, can be considered a bug. I am checking it.
As it is not very breaking, just ugly, I think this can wait until next 1.3 release.

Thanks very much for your detailed feedback!

[memsharded]

Actually I had a bug in my test, I was defining self.cpp_info.libdirs.append("lib"), which is an error, because "lib" is already defined as default, and it was adding it a second time.

Is the package_info() method posted above complete?

[cj-williams]

Yes, that's all I have in package_info()

[memsharded]

Oh, yes, now I know that is happening. It is not a bug, it is intended behavior.

Each "config" sub-configuration has its own includedirs, libdirs, etc. They are defaulted as:

self.cpp_info.includedirs = ["include"]
self.cpp_info.libdirs = ["libs"]
self.cpp_info.debug.includedirs = ["include"]
self.cpp_info.debug.libdirs = ["libs"]
self.cpp_info.release.includedirs = ["include"]
self.cpp_info.release.libdirs = ["libs"]

Then, the generator defines the includedirs and libdirs for "release" as those general to both configs plus the release one, so: self.cpp_info.includedirs + self.cpp_info.release.includedirs. And this is why it appears 2 times.

So in order to avoid the duplication, please define it completely:

def package_info(self):
    self.cpp_info.release.libs = ["hello"]
    self.cpp_info.debug.libs = ["hello_D"]
    self.cpp_info.debug.includedirs = []
    self.cpp_info.debug.libdirs = []
    self.cpp_info.release.includedirs = []
    self.cpp_info.release.libdirs = []

I will check if this can be defaulted without breaking in next release, or in any case to improve the docs accordingly.

[memsharded]

I have added in https://github.com/conan-io/conan/pull/2740 a possible PR that would avoid such initialization. However, not sure that it will be merged, it can be breaking. And even if it is merged, the above initialization in package_info() will keep working perfectly.

[cj-williams]

ahh now I understand - that fix works, thanks!

[memsharded]

The PR https://github.com/conan-io/conan/pull/2740 has been merged into develop, so the fix won't be necessary once 1.3 is released (this month).