Docs for Support cmake_module_target_name and cmake_module_file_name in cmake_find_package

reference/conanfile/attributes.rst

@@ -1038,68 +1038,121 @@ has **the same default directories**.
 Dependencies among components and to components of other requirements can be defined using the ``requires`` attribute and the name
 of the component. The dependency graph for components will be calculated and values will be aggregated in the correct order for each field.
 
-There is a new way of setting and accessing ``filenames``, ``names`` and ``build_modules`` starting
-in Conan 1.36 using new ``set_property`` and ``get_property`` methods of the ``cpp_info`` object:
+**New properties model for the cpp_info**
+
+Using ``names``, ``filenames`` and ``build_modules`` is **deprecated** from Conan 1.42. The
+recommended way of setting this information is using ``set_property`` and ``get_property`` methods
+(available since Conan 1.36) of the ``cpp_info`` object.
 
 .. code-block:: python
 
     def set_property(self, property_name, value, generator=None)
     def get_property(self, property_name, generator=None):
 
-New properties ``cmake_target_name``, ``cmake_file_name``, ``pkg_config_name`` and
-``cmake_build_modules`` are defined to allow migrating ``names``, ``filenames`` and ``build_modules``
-properties to this model.
-In Conan 2.0 this will be the default way of setting these properties and also passing custom
-properties to generators.
+New properties ``cmake_target_name``, ``cmake_file_name``, ``cmake_module_target_name``,
+``cmake_module_file_name``, ``pkg_config_name`` and ``cmake_build_modules`` are defined to allow
+migrating ``names``, ``filenames`` and ``build_modules`` properties to this model. In Conan 2.0 this
+will be the default way of setting these properties and also passing custom properties to generators.
+These properties are supported by the new :ref:`CMakeDeps<CMakeDeps Properties>` and
+:ref:`PkgConfigDeps<PkgConfigDeps Properties>` generators.
+
+New properties defined for *CMake* generators family:
+
+- **cmake_file_name** property will affect all cmake generators that accept the ``filenames``
+  property (*cmake_find_package* and *cmake_find_package_multi*).
+- **cmake_target_name** property will affect all cmake generators that accept the ``names`` property
+  (*cmake*, *cmake_multi*, *cmake_find_package*, *cmake_find_package_multi* and *cmake_paths*).
+- **cmake_module_file_name** property supported by *cmake_find_package* generator. Sets the file name of the
+  module files created by this generator.
+- **cmake_module_target_name** supported by *cmake_find_package* generator. Sets the target name of the
+  module files created by this generator.
+- **cmake_build_modules** property replaces the ``build_modules`` property.
+
+Properties related to *pkg_config*:
+
+- **pkg_config_name** property sets the ``names`` property for *pkg_config* generator.
+- **pkg_config_custom_content** property supported by the *pkg_config* generator that will add user
+  defined content to the *.pc* files created by this generator
+
+All of these properties, but ``cmake_file_name`` and ``cmake_module_file_name`` can be defined at
+global ``cpp_info`` level or at component level.
+
+For most cases, it is recommended not to use the ``generator`` argument. The properties are generic
+for build systems, and different generators that integrate with a given build system could be reading
+such generic properties. 
 
-For most cases, it is recommended not to use the ``generator`` argument. The properties are generic for build systems, and different generators that integrate with a given build system could be reading such generic properties.
-For example, setting some cpp_info properties with the current model:
+Migrating from `cpp_info.names` and `cpp_info.filenames` to `set_property()` is easy, for example
+with the old model you had to set the `names` and `filenames` for each generator if it was different from
+the package name. Now, it's only necessary to set the property and all the generators from the same
+family will read it. For example:
 
 .. code-block:: python
 
     def package_info(self):
         ...
         self.cpp_info.filenames["cmake_find_package"] = "MyFileName"
         self.cpp_info.filenames["cmake_find_package_multi"] = "MyFileName"
+        self.cpp_info.names["cmake_find_package"] = "MyTargetName"
+        self.cpp_info.names["cmake_find_package_multi"] = "MyTargetName"
+        ...
+
+Could be declared like this with `set_property()`:
+
+.. code-block:: python
+
+    def package_info(self):
+        ...
+        self.cpp_info.set_property("cmake_file_name", "MyFileName")
+        self.cpp_info.set_property("cmake_target_name", "MyTargetName")
+        ...
+
+As we said, these properties but ``cmake_file_name`` and ``cmake_module_file_name`` have components
+support, so for example:
+
+.. code-block:: python
+
+    def package_info(self):
+        ...
         self.cpp_info.components["mycomponent"].names["cmake_find_package"] = "mycomponent-name"
         self.cpp_info.components["mycomponent"].names["cmake_find_package_multi"] = "mycomponent-name"
+        self.cpp_info.components["mycomponent"].names["pkg_config"] = "mypkg-config-name"
         self.cpp_info.components["mycomponent"].build_modules.append(os.path.join("lib", "mypkg_bm.cmake"))
         ...
-        self.cpp_info.components["mycomponent"].names["pkg_config"] = "mypkg-config-name"
 
 Could be declared like this in the new one:
 
 .. code-block:: python
 
     def package_info(self):
         ...
-        self.cpp_info.set_property("cmake_file_name", "MyFileName")
         self.cpp_info.components["mycomponent"].set_property("cmake_target_name", "mycomponent-name")
         self.cpp_info.components["mycomponent"].set_property("cmake_build_modules", [os.path.join("lib", "mypkg_bm.cmake")])
+        self.cpp_info.components["mycomponent"].set_property("pkg_config_name", "mypkg-config-name")
         self.cpp_info.components["mycomponent"].set_property("custom_name", "mycomponent-name", "custom_generator")
         ...
-        self.cpp_info.components["mycomponent"].set_property("pkg_config_name", "mypkg-config-name")
 
-New properties defined:
-
-- **cmake_file_name** property will affect all cmake generators that accept the ``filenames``
-  property (*cmake_find_package* and *cmake_find_package_multi*).
-- **cmake_target_name** property will affect all cmake generators that accept the ``names`` property
-  (*cmake*, *cmake_multi*, *cmake_find_package*, *cmake_find_package_multi* and *cmake_paths*).
-- **cmake_build_modules** property will replace the ``build_modules`` property.
-- **pkg_config_name** property will set the ``names`` property for *pkg_config* generator.
-
-There's also a new property called ``pkg_config_custom_content`` defined for the *pkg_config*
-generator that will add user defined content to the *.pc* files created by this generator.
+Also, for the other properties like `pkg_config_custom_content` you just have to set the property and
+the generators that support that (in this case `pkg_config` and `PkgConfigDeps`) will read it without
+having to set the generator name.
 
 .. code-block:: python
 
     def package_info(self):
         custom_content = "datadir=${prefix}/share"
         self.cpp_info.set_property("pkg_config_custom_content", custom_content)
 
-All of these properties, but ``cmake_file_name`` can be defined at global ``cpp_info`` level or at
-component level.
+This mechanism is also very useful if you are creating a :ref:`custom generator<custom_generator>`.
+Using `set_property()` you can pass the parameters of your choice and read them using the
+`get_property()` method inside the generator.
+
+.. code-block:: python
+
+    def package_info(self):
+        ...
+        # you have created a custom generator that reads the 'custom_property' property and you set here
+        # the value to 'prop_value'
+        self.cpp_info.components["mycomponent"].set_property("custom_property", "prop_value")
+        ...
 
 .. warning::
 

reference/conanfile/tools/cmake/cmakedeps.rst

@@ -155,6 +155,7 @@ Use the **build_context_build_modules** attribute to specify require names to in
     The ``build_context_build_modules`` feature will fail if no "build" profile is used. This feature only work when using
     the two host and build profiles.
 
+.. _CMakeDeps Properties:
 
 Properties
 ++++++++++

reference/conanfile/tools/gnu/pkgconfigdeps.rst

@@ -8,6 +8,7 @@ PkgConfigDeps
 
     These tools are **experimental** and subject to breaking changes.
 
+.. _PkgConfigDeps Properties:
 
 PkgConfigDeps
 -------------