Repository: conan-io/conan

Issue:
cmake_find_package generator does not produce CONAN_RES_DIRS_ variables
In my package recipe, I do the following:

```py
    exports_sources = "res/*"

    def package(self):
        self.copy("*", dst="res", src="res")

    def package_info(self):
        self.cpp_info.resdirs = ['res']
```
In the resulting package, the resource files are present, but for projects that consume this package via the cmake_find_package generator, the generated Findx.cmake file does not contain any CONAN_RES_DIRS_ variables, which was confirmed by another user in the Conan slack. 

I also checked the normal cmake generator and it seems to have the correct behaviour.


Discussion:
Could I ask what do you have in the "res" directory to understand why you need it from CMake?
Thanks for creating the issue.
The project that this pertains to is a shared library which builds out a set of common comm functions for our team using a communication middleware called DDS (realtime pub/sub over UDP, used in ROS2). One major aspect of DDS is the concept of Quality of Service profiles, which basically serve as contracts for the publishing and subscribing endpoints to agree upon how they will communicate (reliable, best effort, etc). You can specify these profiles either programmatically or load them at runtime through XML files. 

The XML approach makes it easy to quickly tweak certain settings between runs, and thus distributing our standard qos.xml file as a resource within the library is useful for giving users of our library a good starting point, but allowing them to tweak the file if desired.

In our internal projects, we are using ROS's catkin build system, which unfortunately has some incompatibility with Conan's standard CMake generator (I believe either the generated Conan Cmake file or Catkin's internals are trampling over variables that the other depends on having been set a certain way). For this reason, we use the cmake_find_package generator, which nicely integrates within a ROS project.

Our approach to making sure all of our programs have access to the shared XML files was going to be adding an install step to our application's CMakefile.txt, which depends on the shared library conan package via find_package() and uses the CONAN_RES_DIR variable to know where to find the file and copy it to some location in the install directory along with our final binaries.

Confirming this. Even when using `conan_basic_setup(TARGETS)` instead of `conan_basic_setup()`, something is interfering with the ability to do `find_package(catkin ...)`. At a quick glance, nothing seems to be wrong with `CMAKE_MODULE_PATH`.

As a workaround it seems to work when `include(.../conanbuildinfo.cmake)` and `conan_basic_setup(TARGETS)` are done after `find_package(catkin)`.
@ysono I'm not sure if this is the same issue as @spiderkeys described. For him I think (correct me if I'm wrong) the `find_package` is working but he needs the variable `CONAN_RES_DIRS_` present.
You're right, I conflated 2 issues.

- Findxxx.cmake doesn't define CONAN_RES_DIRS_XXX
- `cmake` generator + `conan_basic_setup()` doesn't work with catkin ; `cmake` generator + `conan_basic_setup(TARGETS)` works with caveat. This one may not be conan's fault. More investigation is needed, and a request should be filed separately.

Resolving patch:
diff --git a/conans/client/generators/cmake_find_package_common.py b/conans/client/generators/cmake_find_package_common.py
--- a/conans/client/generators/cmake_find_package_common.py
+++ b/conans/client/generators/cmake_find_package_common.py
@@ -1,6 +1,7 @@
 target_template = """
 set({name}_INCLUDE_DIRS{build_type_suffix} {deps.include_paths})
 set({name}_INCLUDES{build_type_suffix} {deps.include_paths})
+set({name}_RES_DIRS{build_type_suffix} {deps.res_paths})
 set({name}_DEFINITIONS{build_type_suffix} {deps.defines})
 set({name}_LINKER_FLAGS{build_type_suffix}_LIST "{deps.sharedlinkflags_list}" "{deps.exelinkflags_list}")
 set({name}_COMPILE_DEFINITIONS{build_type_suffix} {deps.compile_definitions})


Test patch: