Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Using conan build_type with toolchain packages #2497

Closed
3 tasks done
mpdelbuono opened this issue Feb 20, 2018 · 2 comments
Closed
3 tasks done

Using conan build_type with toolchain packages #2497

mpdelbuono opened this issue Feb 20, 2018 · 2 comments

Comments

@mpdelbuono
Copy link
Contributor

To help us debug your issue please explain:

  • I've read the CONTRIBUTING guide.
  • 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?

@lasote
Copy link
Contributor

lasote commented Feb 20, 2018

Hi!
To confirm that I understand it correctly:

  • You have a conan package for the clang compiler.
  • 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.

@mpdelbuono
Copy link
Contributor Author

Ah yes, it looks like #2301 is the same problem. I missed that during my search. Thank you for pointing it out; I'll close this now.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants