[feature] CMake generators: Move includes of build_modules after targets are created in generated CMake find modules

[TimSimpson]

The attribute self.cpp_info.build_modules can be used to set CMake files which get included in the generated find modules created by cmake_find_package.

Today, these include statements are put before the targets which are defined by the generated find module files, rather than at the end of the file, which means the build modules script cannot interact with the exported targets directly.

@danimtb has suggested there may not have been a motivation in putting the build modules before the target, so if the is the case let's move them to the end of the file.

This would enable things like setting additional properties on the targets or creating clones or aliases of them.

• I've read the CONTRIBUTING guide.

[TimSimpson]

cc @GordonJess

[jgsogo]

Hi! Is there any real use-case for this? For example, the target alias, IMO it is not something to be packaged with the library, it is something that belongs to the consumer

[TimSimpson]

I guess my main thinking is, if there is no great reason not to do it, and it offers some flexibility for people wanting to use build modules, then why not?

As for real use cases, my own is of course to create alias targets so I can name the CMake targets used by consumers of my own Conan packages anyway I want. I know upcoming features like this one could make that unnecessary, but it seemed worthwhile to make an issue to tackle the problem from this angle as well, especially since it appears so unintrusive to Conan itself.

I know @gordonjess mentioned wanting to set a custom property on the target, so maybe he could comment here too.

[jgsogo]

I've just realized that this issue was here and I opened another one: #7352

I'm copying here what I've written in the other one after talking with the team and I'll close that one:

This is a last-mile problem for CMake. Some packages provide CMake modules with some customization that doesn't fit the general conventions and we cannot keep adding more complexity to the cpp_info model:

• OpenSSL has a different casing for the filename and the variables provided by it: https://cmake.org/cmake/help/v3.6/module/FindOpenSSL.html
• cereal provides a cereal-config.cmake that offers targets without namespace (conan-io/conan-center-index#2151), SPIRV-tools too (IIRC).
• ...there are many details hidden in other packages

If we really want to provide transparent integration, this last-mile details cannot be supported in the cpp_info, but they can be added to the build_modules, those files are included for all the CMake generates and they can populate other variables based on the value of existing ones and they could create custom targets (or alias)...

To be able to implement this feature, some work/research to be done:

• include build_modules after creating the targets for cmake_find_package[_multi] generators.
• build_modules need to know the generator used, so they know if targets are available or not (depending on the generator, or even depending on the TARGET argument to conan_basic_setup).

[Croydon]

IIRC I struggled with the current behaviour too with either protobuf or grpc

👍