Using build type in components

[steffenroeber]

Example:
Old golbal approach
self.cpp_info.debug.libs += [Qt5Cored]
self.cpp_info.release.libs += [Qt5Core]

New approach with components:
self.cpp_info.components["Core"].libs = ["Qt5Cored"] #debug
#self.cpp_info.components["Core"].libs = ["Qt5Core"] #release
self.cpp_info.components["Core"].requires = ["openssl::openssl"] #same for debug and release
Is their any plan to support different buid_type for specifying component?

Best regards
Steffen

[uilianries]

@steffenroeber I don't think it requires a new feature for components. We already use if condition to filter any setting. Thus, you can do:

if self.settings.build_type = "Debug":
    self.cpp_info.components["Core"].libs = ["Qt5Cored"]
else:
    self.cpp_info.components["Core"].libs = ["Qt5Core"] #release

OR

lib_suffix = "d" if self.settings.build_type == "Debug" else ""
self.cpp_info.components["Core"].libs = ["Qt5Core" + lib_suffix]

Again, it's not a new concept, this approach is the regular used for any recipe.

[memsharded]

To clarify a bit more about future plans: there are no plans to support multi-config components. With the new "multi" generators, like cmake_find_package_multi and msbuild, it is becoming less an issue to consume different configurations packaged in single-config Conan packages. It is likely that Conan 2.0 will deprecate multi-config packages (it will be discussed first).

[steffenroeber]

Ok. Thank you. Could you say when the cmake generator will support components?

[jgsogo]

Hi! The idea is to deprecate the cmake generator for Conan 2.0 and, besides that, it is not possible to provide the components with that generator, it offers and unique namespace CONAN_PKG:: for all the targets, there is no room for them: CONAN_PKG::OpenSSL::SSL.

With the introduction of the new toolchain feature the main functionality of the cmake generator is totally superseded. We will (90% sure) still provide a generator for backward compatibility with plain variables, without targets.

Anyway, as said before, we would love to hear from your use-case to know if we are missing something and deprecating these things will be a blocker for some of our users. Will the approach suggested by @uilianries work for you? Do you see any problem if cmake generator is deprecated in favor of cmake_find_package+toolchain?

Thanks!

[steffenroeber]

I currently evaluate migrating from cmake to cmake_find_package toolchain.
My current problem is following. Have a conan recipe to build a lib like Qt that depends on for example icu
If Qt has a build_type (e.g. Debug) but icu has no (because we want to use it only in Release mode), what's the prefered way doing this? Normally Conan would say, that both are incompatible. Clearly: I want to have Qt in debug and release but icu only in release.

Best regards

[jgsogo]

There are other alternatives you can consider:

• you can modify the icu recipe, remove the build_type from the settings so Conan computes the same package-ID for build_type=Debug and build_type=Release and build/upload only the release one. Conan will use that one always. The main problem with this approach is that you will be losing information.

• (much better) you can add to your debug profiles (or to the command line) a line to force icu release package. No need to modify the original recipe, no information is lost:

  [settings]
  ...
  build_type=Debug
  icu:build_type=Release

[steffenroeber]

Your second approach sounds smart. But I couldn't apply it in my conanfily.py:

 def configure(self):
        if self.options.icu:
            self.settings["icu"].build_type = "Release"

This gives me an error. Is it possible to set build_type of icu in conanfile.py?

[jgsogo]

I would strongly discourage that approach. It couples your QT recipe with a hack. If you cannot add that line to your profiles I would modify the ICU recipe, but not the consumers. You can fork the recipe you are using (the Conan Center one?)

class ICURecipe(ConanFile):
    settings = "os", "arch", "compiler", "build_type"

    def build(self):
        if self.settings.build_type == "Debug":
            raise ConanInvalidConfiguration("In this company, ICU in Debug mode is not allowed")

    def package_id(self):
        del self.info.settings.build_type

With these changes you ensure that noone will build the Debug configurations and upload it, and you will get the same package-id for build_type=Debug and build_type=Release. In the end, you will always use the Release ICU library.

Anyway, once again, I would recommend you the profiles approach.

[steffenroeber]

Thanx a lot. I'll try this profile approach.

[jgsogo]

Great! I'm closing this issue now, but feel free to open or comment if you need help/advice/opinion about it.

Thanks!

[steffenroeber]

I actually have one more question but I don't know if this is the right place to ask.
I use something like:
conan install .. -sbuild_type=Debug -gcmake_find_package_multi
conan install .. -sbuild_type=Release -gcmake_find_package_multi
This creates me the specified cmake files.
Then in my cmakelist I use
find_package(Qt5 REQUIRED CONFIG)
This works all targets are known. But now something like automoc does not work anymore:

CMake Error: AUTOGEN: No valid Qt version found for target cbl. AUTOMOC disabled.
Consider adding:
find_package(Qt COMPONENTS Core)
to your CMakeLists.txt file.

Previously I used find_package(Qt5Core REQUIRED) (the find package from cmake itself).
What the idea? Can I mix both or do I have to add automoc logic to the Qt recipe?
The Qt recipe looks like:
`
def package_info(self):
self.cpp_info.name = "Qt5"

    for lib in tools.collect_libs(self):
        name, ext = os.path.splitext(lib)
        if name.startswith("Qt5"):
            cmpname = name[3:]
            if self.settings.build_type == "Debug":
                cmpname = name[:-1]
            self.cpp_info.components[cmpname].libs += [name]

    self.cpp_info.components["Core"].requires = ["icu::icu"]
    self.cpp_info.components["Network"].requires = ["openssl::openssl"]

`

Best regards

[steffenroeber]

Meanwhile, I found that I may add a moc target in components, too.
But unforunately
self.cpp_info.components["moc"].exe = ["bin/moc.exe"]
seems not to work. Is this supported?

[uilianries]

seems not to work. Is this supported?

No.

If you want to export your application, you add it to PATH and set a specific variable for that app. For instance: https://github.com/conan-io/conan-center-index/blob/3e43313932c67d04539e8ceecc1ba3cb6d60cd33/recipes/autoconf/all/conanfile.py#L84

Please, read Components documentation for further information.
https://docs.conan.io/en/latest/creating_packages/package_information.html#package-information-components

[steffenroeber]

self.env_info.PATH.append(bin_path) seems not to work with cmake_find_package(_multi)

[steffenroeber]

Isn't #5408 exactly what I mean/need? Was/will this be merged anytime?

[uilianries]

self.env_info.PATH.append(bin_path) seems not to work with cmake_find_package(_multi)

You need to associate the RunEnvironment to append the PATH, it won't happen directly to your system. If you are only consuming the recipe, you should use virtualrunenv generator too.

Isn't #5408 exactly what I mean/need? Was/will this be merged anytime?

No. The PR was closed months ago, the current state doesn't provide that. If you wish that component,
please, open a new issue asking.

Please, follow #7240, that's the new feature for your topic.