[feature] Allow conan install `--build=...` to distinguish between build requirements & target requirements

[stevenwdv]

What is your suggestion?

I'd like to have a way for conan install --build=... to specify build requirements vs target ('host') requirements. E.g. --build=host:* and --build=build:b2/*.

This way I can easily force a build from source excluding build requirements.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @stevenwdv

Thanks for the feedback.

This way I can easily force a build from source excluding build requirements.

I'd like to understand a bit better the pain.
In general, it is not necessary, and actually not recommended in most cases, to force the build of things from source. Packages only need to be built from source when missing, that is --build=missing, or a explicit one that is computed from a conan graph build-order command. But something like conan install --build=pkg/version is generally not recommended, as it could be re-building a package binary that already exists.

And then, the build and host context doesn't really matter much, the packages that doesn't exist need to be build from source anyway. And if it is a CI pipeline that want to guarantee that strictly one specific package is built if it doesn't exist, the --build=missing:pkg/version syntax exists.

[stevenwdv]

In general, it is not necessary, and actually not recommended in most cases, to force the build of things from source.

True, usually significant configuration should be covered by settings and options, which will be incorporated in the package ID, triggering a rebuild when necessary.

Sometimes I want to experiment with different compiler flags. An example would be -fexceptions vs -fwasm-exceptions for WebAssembly with Emscripten (objects with different exception models cannot be mixed). But even then it's probably better to just do this:

tools.info.package_id:confs=['tools.build:cflags', 'tools.build:cxxflags', 'tools.build:exelinkflags', 'tools.build:sharedlinkflags', 'tools.build:defines']

---

However, in today's case, I do think the --build=* option was justified, although correct me if I'm wrong: I updated the Emscripten SDK (emsdk) on my devbox and needed to be sure that the bug I was seeing in our app wasn't caused by a mismatch between versions (dependencies being built by an older version than our app). So, I wanted to rebuild all requirements using the Emscripten compiler, but not build tools like cmake or b2 as these aren't using the Emscripten compiler anyway.

Normally, I guess the compiler.version setting should probably cover compatibility (or does it?) but...

1. I'm not sure if there may be other components of the emsdk like binaryen or their Python scripts that may be incompatible between versions.
2. compiler.version doesn't work well with emsdk as it uses a development version of the clang compiler (currently 22), which is not allowed by Conan's settings.yml, so I need to manually set it to the closest release (currently 21).

Edit: Since #18432, the emcc compiler.version may solve this, but I'm don't know if it always forces a rebuild?

[HekyM]

Hi, I would like to add one use case I can see. I don't found it as required feature, but I would consider it as useful.

As many other parameters already support their context versions (--options --options:host --options:build, ...). It will fit well, to have also --build --build:host --build:build ... (yean build:build is a bit weird one)

Use case I can see is eg local debugging. if I not pack debug symbols by default, only way to have debug symbols is to force rebuild. In case I need to debug something used in both, host and build context (protobuf etc) and doing cross-build (x86_64 -> armv8), there is no way to force rebuild only host one. With --build:host=protobuf/* I would be able to target only required one.

[memsharded]

In case I need to debug something used in both, host and build context (protobuf etc) and doing cross-build (x86_64 -> armv8), there is no way to force rebuild only host one. With --build:host=protobuf/* I would be able to target only required one.

But this one will also naturally happen with a:

conan install ... -s protobuf/*:build_type=Debug --build=missing:protobuf

Because that only changes the "host" settings, and even if the same package is also in the "build" context, that existing binary will still be valid and won't require a re-build from source.

[stevenwdv]

I just found another usecase: I wanted to monitor what it did while building (procmon on which commands it called), but only for the cross-compiled package, not the one for the build context.

I agree with @HekyM that the syntax --build --build:host --build:build ... would make the most sense.

[memsharded]

I just found another usecase: I wanted to monitor what it did while building (procmon on which commands it called), but only for the cross-compiled package, not the one for the build context.

That is the thing I don't fully understand yet.
The scenarios and commands above, like:

conan install ... -s protobuf/*:build_type=Debug --build=missing:protobuf

Do not build the one in the build context. It is only built if it doesn't exist, in which case, it is necessary to build it first, otherwise things will fail anyway because of the missing binary.

[stevenwdv]

I agree, but why are you mentioning missing? To clarify, this issue is about rebuilding packages that are not missing, i.e. --build='package/*'. Usually this is not necessary, but sometimes you want to see if a change in your environment messes up the build, or you want to check what binaries it's actually using, for example, and preferably want to limit the rebuild to one context.

[HekyM]

This is about ability to target --build only to specific context. Examples mentioned here, is a usecase to FORCE rebuild of existing package in host context only, when the same package is also in build context.
Reason why I need to do that may be different. In my case, I would like to force rebuild package with more debug information, no optimizations, etc because I need to debug some issue that looks like be in that package.

Example:

conanfile.txt

[requires]
...
protobuf/1.2.3
...

[tool_requires]
...
protobuf/123
...

install dependencies for my app (normal usecase)

conan install conanfile.txt -pr:b my-x86_64 -pr:h my-armv8 -g MSBuildDeps

install dependencies for my app (FORCE rebuild protobuf in host (armv8) for debugging)

set CL=/Od
conan install conanfile.txt -pr:b my-x86_64 -pr:h my-armv8 -g MSBuildDeps --build=protobuf/*

In this case, I'm unable to target package only in host context. This will rebuild both host + build package

set CL=/Od
conan install conanfile.txt -pr:b my-x86_64 -pr:h my-armv8 -g MSBuildDeps --build:host=protobuf/*

In this case, I can target only host package because I don't need to rebuild build version

This is a bit crafted use case. And as I say previously, I don't found it as required feature. But still it might be useful and cannot be "mimic" with current cli support.

[memsharded]

Thanks for the feedback.

I can't guarantee, but I am doing #19746 as a possible first refactor to consider this feature on top of it.