[feature] --target argument for conan build

Following the broader discussion in #5553 i suggest the following feature mainly relevant for CI but also for local development: For doing “non-standard” builds like generating documentation output or running a static code analysis people usually create optional build targets in the used build system, e.g. CMake.

As there is most probably no need to include the generated files in the Conan packages, the build is done with conan install && conan build in the userspace to easily access the files for uploading, archiving, … To avoid having to call the underlying build system directly in the CI builds (may also be used locally by developers so they do not have to run activate.bat and call CMake directly with all required parameters), the actual build target could be passed directly with e.g. conan build --target docs to the build() method, similar to the --configure, --build, --test flags and the respective attributes.

This would avoid having to add dedicated options for all these “non-standard” builds in the conanfile.py which are not used for package creation anyway.

• I’ve read the CONTRIBUTING guide.

[jgsogo]

Hi! No news about this.

Conan v2.0 will include a new command-line interface that makes it possible to add user-defined commands (some preliminary PRs are already merged). This new CLI together with a good documentation of the Conan API opens a new set of possibilities, but IMHO it’s not enough for this --target argument/need.

I’m not sure if this is something desired for the conan build command or it is more related to the editables feature (install the package as editable and then run local tools/commands). We are facing many issues with the local developer workflow not behaving exactly the same way as the conan create and it might not be the best idea to add more complexity (or flexibility) to it if it is not 100% needed.

Maybe this issue is a symptom of something different: we usually don’t generate and package things like docs, benchmark results, static code analysis reports,… because we don’t need this information always, we don’t want to add more options and generate different packages with and without this extra files. If this is the symptom, it is more related to the ongoing discussions about quality artifacts, PDBs,… and we are thinking a way to handle this files and add them to the package if available without affecting the package-id.

[petermbauer]

Thanks for sharing @RolfBippus, i also considered removing it from the package_id but for me its ok to produce different binary packages as the content depends on which target is built.