0

Our development workflow forces us to always deploy a specific 3rd party dependency in Release mode whether we're developing or releasing the final product.

I'd like to be able to make this specific build available when I'm developing, ie, all libraries are deployed in debug mode, and during release, when everything is deployed in Release mode.

I'm currently setting self.info_build.settings.build_type = "Any" but the library is not available when deploying in Debug mode. Is the solution to have two packages, one in Release and one in Debug mode and then force CMake to always create a Release build or is there another way?

ruipacheco
  • 15,025
  • 19
  • 82
  • 138
  • I think that you should remove `build_type` from `settings` in conan file of that library and set `CMAKE_BUILD_TYPE` to `Release` instead of setting `self.info_build.settings.build_type`. – joe_chip Aug 06 '19 at 11:28
  • @joe_chip no luck. Package still won't install when I pass -s build_type=Debug, only in Release mode. I suspect I have to create two packages. – ruipacheco Aug 06 '19 at 13:38

1 Answers1

1

You can create multiple profiles, one per stage:

# develop profile
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
build_type=Debug
third_party:build_type=Release
[options]
[build_requires]
[env]
# deploy profile
include(develop)

[settings]
build_type=Release

These profiles will force your third party to be built in release mode, as you asked before. All other libraries will follow the general build type.

To build your project, you can use Conan commands as well, but using the explicit profile:

conan install .. -p develop # for development
conan install .. -p deploy # for deployment

Using this solution you will be able to consume your third party in release mode, regardless the general build type.

You can more information about Conan profiles here: https://docs.conan.io/en/latest/reference/profiles.html

Regards!

uilianries
  • 3,363
  • 15
  • 28
  • I'm trying to create the package myself. I want to have a Release build that is seamlessly installable as a dependency of Release and Debug builds of our core product. – ruipacheco Aug 06 '19 at 13:26
  • you said that you have a third party which is release only, but your build can be release or debug. I don't know which process are you following to "deploy" you application, but for mixed build types, you can use profiles to avoid explicit arguments. – uilianries Aug 06 '19 at 14:30
  • if you want to re-use the same package id for development and deploying, you could use a hook to strip your binaries. But it's not a good approach IMO, you should have two package ids, because of reproducibility. Image having a bug in production which you can't reproduce using debug. Only the release package would contain -O3 flag for instance. – uilianries Aug 06 '19 at 14:33
  • My apologies, I meant to say that we build it ourselves. So it's not possible to create a package that works for both release and debug at the same time? – ruipacheco Aug 07 '19 at 06:36
  • Now I see your point, you need to exclude the build type from that package, as joe_chip commented before. When declaring setting in the recipe, remove settings from there: `settings = "os", "arch", "compiler"`. Then Conan won't consider build type as property which change the package id. – uilianries Aug 07 '19 at 11:23
  • So I need to remove all of them? If that's the case how do I distinguish between a Linux and a Windows build? I tried to remove the build_type but it wouldn't install when I did `conan install . -s build_type=Debug` (I wanted other packages to be debug builds). – ruipacheco Aug 07 '19 at 11:36
  • I see, you can remove it from your package id. Which means, when building the package, Conan will detect build_type and will configure your build, but when creating a package ID, it will be the same for both Debug and Release. There is a specific section about it on Conan docs: https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html. For your specific case, you only need to remove build_type in package_id() method: `del self.info.settings.build_type`. Using this approach you don't need to remove build_type from your settings, so you can keep all them. – uilianries Aug 07 '19 at 13:27