Make it possible to capture the JSON output of the conan install command(s)

[craigscott-crascit]

In the implementation of the conan_install() function, the conan install command output is specified to be in JSON format and is captured to a CMake variable. However, the contents of that variable are not made available to the project in any way. One of the really handy uses of that output is to check which packages ended up being built from source instead of retrieving a pre-built binary package from one of the remotes. It can also be used as part of uploading just-built binary packages when one or more dependencies had to be built-on-demand due to missing binary packages.

One potential complication is where multiple calls to conan_install() are made. Right now, that's the case when a multi-config generator is used. #705 proposed a feature where the project can specify whichever build configuration(s) it wants, including supporting multiple configurations for a single-config generator if they want to. So a feature like what is being proposed here would need some way of saving the results of multiple runs and the project being able to differentiate the separate per-config output.

Perhaps one solution would be to save the output to config-specific files in the output folder. That wouldn't require any new keyword or variable, we could just write these files always. That would certainly help with debugging what's going on with fulfilling dependencies. I use such a file frequently in production projects where I can't currently use cmake-conan, and it would solve some problems I face with those projects that do use cmake-conan.

[jcar87]

Hi @craigscott-crascit - thanks for opening this issue.

If I'm reading this correctly, I think it would be sensible just to output these files somewhere to CMAKE_BINARY_DIR, and perhaps choose different filenames in case there are multiple invocations, right? (on the later point, I think they could be merged into a single one with conan pkglist (docs), but I'd need to check with team to make sure that is the case)

[craigscott-crascit]

Merging them when there's more than one build type/configuration might simplify things for the project, especially if combined with my suggestion in #705 for allowing the project to specify the build type(s) they want installed. I'm already doing the merge packagelist thing in at least one project where I've been carrying patches to cmake-conan for this.

As for the directory where we write the file(s), why not put them in the conan generation directory along with all the other files conan writes?

[jcar87]

Merging them when there's more than one build type/configuration might simplify things for the project, especially if combined with my suggestion in #705 for allowing the project to specify the build type(s) they want installed. I'm already doing the merge packagelist thing in at least one project where I've been carrying patches to cmake-conan for this.

I'll do some testing to see if pkglist is suitable for this, I think it would make sense.

As for the directory where we write the file(s), why not put them in the conan generation directory along with all the other files conan writes?

I think this makes sense. I need to double check if this can be generalised, in the case of multiple invocations of conan install (e.g. multi-config generator) I'm thinking that theoretically a Conan layout may cause the output directory to be different per-configuration - which may be a little tricky if we want a single merged file, although at the same time it would make it easier if we're okay with separate files per invocation. Ideally we do both !