conan-io / conan

Conan - The open-source C and C++ package manager
https://conan.io
MIT License
8.22k stars 980 forks source link

[feature] Allow overriding settings for specific dependencies (tools) #10092

Open dribeas opened 2 years ago

dribeas commented 2 years ago

Conan allows overriding options but not settings when installing dependencies (and build dependencies). You can in the command line determine that you want to build shared objects and link one of your dependencies statically, for example.

There are some packages, though, that are used as tools and for which there's no relation between what you want to build and how you consume that dependency. For example cmake is used as a tool, and you don't need to have a DEBUG build of cmake to be able to build your own code in debug mode.

In cases like cmake it may be possible to remove those bits from the settings (i.e. the settings for the cmake package could omit the build_type ([§]). But this cannot be done with other tools like strawberryperl which can be both a tool in some projects (we use some perl in our build system, don't judge!) but can also be a library.

There could be different ways of going about this, one would be to separate the tool from the library, and have strawberryperl-lib and strawberryperl-interpreter packages, the former having all the options in the settings, the latter ignoring a few. But the point of compiling against the strawberryperl-lib would still be to run it in an interpreter, and we are back at having to match the interpreter with the library (which is exactly what we have now with a single package).

An alternative is to postpone the decision to the user. If you know that you only want the interpreter and you don't care about which you could override either in the recipe or in the command line the settings for the dependency:

# Syntax for exposition only, building debug/32
$ conan install my_pkg/1.0 --build=missing -pr debug_32_profile -s strawberryperl:build_type=Release -s strawberryperl:arch=x86_64

Note that the -s:b and -s:h are in the same space, but it may be a bit blunt as it separates all the build_requires vs. requires in the recipe. I could imagine that you may have a build_depends for which the build_type or arch matter.

A more radical approach would be to consider that there are really requires, build_requires and build_tools and that the settings/options may apply differently to those three categories.

[§] This is not what cmake does in conan-center-index; they include arch, compiler and build_type in the settings but remove compiler from the package_id(). This means that I need to have a DEBUG build of cmake. I'm also unsure about the idea of building distinct things with the same identifier in the first place...

SpaceIm commented 2 years ago

Note that the -s:b and -s:h are in the same space, but it may be a bit blunt as it separates all the build_requires vs. requires in the recipe.

Why don't you want to use -s:b and -s:h? Separating build requires and requires is the good approach. If I'm not wrong, it will be the default behavior in conan v2. 2 profiles + always force -s:b build_type=Release if you want to ensure Release build for your tools.

You may want to read this discussion in conan-center-index: https://github.com/conan-io/conan-center-index/issues/3157