You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've specified the Conan version, operating system version and any tool that can be relevant.
I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.
Conan v1.0.4
Is there a preferred mechanism through which compilers' (and other toolchain elements') packages are defined? In particular, build_type is standing out at me as a troublesome item.
Consider that I have a clang package. Because I actually work on clang, I will occasionally want to build it in debug mode with assertions enabled, because the developers actually working on the compiler will want those enabled to help troubleshoot problems.
However, this compiler is also consumed by others. They simply add the package to build_requires, but a problem arises when they want to use build_type Debug. They don't actually want the debug version of the compiler; they assume the compiler works. However, their system they do want to run in debug mode. Unlike the actual product they are building, which needs to be consistent across the board, there is no need to use the debug version of the compiler for ABI compatibility.
My first instinct was to use package_info to try to override the package's settings, but I'm starting to realize that this would cause trouble for the compiler developers. Effectively we have two different contexts: one where the build_type matters (compiler developers), and one where it does not (compiler users). Is there a good way to use conan to distinguish these cases such that compiler users always grab the release version of the compiler, but compiler developers still have the debug version available?
The text was updated successfully, but these errors were encountered:
That clang package declares "build_type" in the recipe.
When developers "build_require" the "clang" package doesn't mean that they want the compiler in Debug mode when they want the regular requirements in "Debug" mode.
It is related to my latest comment here: #2301 and with this one #2428
We already identified this issue but currently, we don't have a way to solve it. In your case maybe you can build the clang with an option to activate the "Debug" mode until we solve it.
As I said in #2428: We have some ideas of how to solve it, but it looks like instead of declaring different settings for target/build/host, we should consider the whole settings definition as a "context" to apply to target/build/host.
I think it is better to keep the discussion in only one thread. If you agree that it is the same problem, please comment in #2428 your use case and close this one.
To help us debug your issue please explain:
Conan v1.0.4
Is there a preferred mechanism through which compilers' (and other toolchain elements') packages are defined? In particular, build_type is standing out at me as a troublesome item.
Consider that I have a clang package. Because I actually work on clang, I will occasionally want to build it in debug mode with assertions enabled, because the developers actually working on the compiler will want those enabled to help troubleshoot problems.
However, this compiler is also consumed by others. They simply add the package to
build_requires
, but a problem arises when they want to use build_type Debug. They don't actually want the debug version of the compiler; they assume the compiler works. However, their system they do want to run in debug mode. Unlike the actual product they are building, which needs to be consistent across the board, there is no need to use the debug version of the compiler for ABI compatibility.My first instinct was to use package_info to try to override the package's settings, but I'm starting to realize that this would cause trouble for the compiler developers. Effectively we have two different contexts: one where the build_type matters (compiler developers), and one where it does not (compiler users). Is there a good way to use conan to distinguish these cases such that compiler users always grab the release version of the compiler, but compiler developers still have the debug version available?
The text was updated successfully, but these errors were encountered: