aboutsummaryrefslogtreecommitdiff
path: root/modules/ECMSetupQtPluginMacroNames.cmake
diff options
context:
space:
mode:
Diffstat (limited to 'modules/ECMSetupQtPluginMacroNames.cmake')
-rw-r--r--modules/ECMSetupQtPluginMacroNames.cmake190
1 files changed, 95 insertions, 95 deletions
diff --git a/modules/ECMSetupQtPluginMacroNames.cmake b/modules/ECMSetupQtPluginMacroNames.cmake
index e4a03ba5..632149ca 100644
--- a/modules/ECMSetupQtPluginMacroNames.cmake
+++ b/modules/ECMSetupQtPluginMacroNames.cmake
@@ -1,102 +1,102 @@
-#.rst:
-# ECMSetupQtPluginMacroNames
-# --------------------------
-#
-# Instruct CMake's automoc about C++ preprocessor macros used to define Qt-style plugins.
-#
-# ::
-#
-# ecm_setup_qtplugin_macro_names(
-# [JSON_NONE <macro_name> [<macro_name> [...]]]
-# [JSON_ARG1 <macro_name> [<macro_name> [...]]]
-# [JSON_ARG2 <macro_name> [<macro_name> [...]]]
-# [JSON_ARG3 <macro_name> [<macro_name> [...]]]
-# [CONFIG_CODE_VARIABLE <variable_name>] )
-#
-# CMake's automoc needs some support when parsing C++ source files to detect whether moc
-# should be run on those files and if there are also dependencies on other files, like those
-# with Qt plugin metadata in JSON format. Because automoc just greps overs the raw plain text
-# of the sources without any C++ preprocessor-like processing.
-# CMake in newer versions provides the variables ``CMAKE_AUTOMOC_DEPEND_FILTERS`` (CMake >= 3.9.0)
-# and ``CMAKE_AUTOMOC_MACRO_NAMES`` (CMake >= 3.10) to allow the developer to assist automoc.
-#
-# This macro cares for the explicit setup needed for those variables for common cases of
-# C++ preprocessor macros used for Qt-style plugins.
-#
-# JSON_NONE lists the names of C++ preprocessor macros for Qt-style plugins which do not refer to
-# external files with the plugin metadata.
-#
-# JSON_ARG1 lists the names of C++ preprocessor macros for Qt-style plugins where the first argument
-# to the macro is the name of the external file with the plugin metadata.
-#
-# JSON_ARG2 is the same as JSON_ARG1 but with the file name being the second argument.
-#
-# JSON_ARG3 is the same as JSON_ARG1 but with the file name being the third argument.
-#
-# CONFIG_CODE_VARIABLE specifies the name of the variable which will get set as
-# value some generated CMake code for instructing automoc for the given macro names,
-# as useful in an installed CMake config file. The variable can then be used as usual in
-# the template file for such a CMake config file, by ``@<variable_name>@``.
-#
-#
-# Example usage:
-#
-# Given some plugin-oriented Qt-based software which defines a custom C++ preprocessor
-# macro ``EXPORT_MYPLUGIN`` for declaring the central plugin object:
-#
-# .. code-block:: c++
-#
-# #define EXPORT_MYPLUGIN_WITH_JSON(classname, jsonFile) \
-# class classname : public QObject \
-# { \
-# Q_OBJECT \
-# Q_PLUGIN_METADATA(IID "myplugin" FILE jsonFile) \
-# explicit classname() {} \
-# };
-#
-# In the CMake buildsystem of the library one calls
-#
-# .. code-block:: cmake
-#
-# ecm_setup_qtplugin_macro_names(
-# JSON_ARG2
-# EXPORT_MYPLUGIN_WITH_JSON
-# )
-#
-# to instruct automoc about the usage of that macro in the sources of the
-# library itself.
-#
-# Given the software installs a library including the header with the macro
-# definition and a CMake config file, so 3rd-party can create additional
-# plugins by linking against the library, one passes additionally the name of
-# a variable which shall be set as value the CMake code needed to instruct
-# automoc about the usage of that macro.
-#
-# .. code-block:: cmake
-#
-# ecm_setup_qtplugin_macro_names(
-# JSON_ARG2
-# EXPORT_MYPLUGIN_WITH_JSON
-# CONFIG_CODE_VARIABLE
-# PACKAGE_SETUP_AUTOMOC_VARIABLES
-# )
-#
-# This variable then is used in the template file (e.g.
-# ``MyProjectConfig.cmake.in``) for the libary's installed CMake config file
-# and that way will ensure that in the 3rd-party plugin's buildsystem
-# automoc is instructed as well as needed:
-#
-# ::
-#
-# @PACKAGE_SETUP_AUTOMOC_VARIABLES@
-#
-# Since 5.45.0.
-
-#=============================================================================
# SPDX-FileCopyrightText: 2018 Friedrich W. H. Kossebau <kossebau@kde.org>
#
# SPDX-License-Identifier: BSD-3-Clause
+#[=======================================================================[.rst:
+ECMSetupQtPluginMacroNames
+--------------------------
+
+Instruct CMake's automoc about C++ preprocessor macros used to define Qt-style plugins.
+
+::
+
+ ecm_setup_qtplugin_macro_names(
+ [JSON_NONE <macro_name> [<macro_name> [...]]]
+ [JSON_ARG1 <macro_name> [<macro_name> [...]]]
+ [JSON_ARG2 <macro_name> [<macro_name> [...]]]
+ [JSON_ARG3 <macro_name> [<macro_name> [...]]]
+ [CONFIG_CODE_VARIABLE <variable_name>] )
+
+CMake's automoc needs some support when parsing C++ source files to detect whether moc
+should be run on those files and if there are also dependencies on other files, like those
+with Qt plugin metadata in JSON format. Because automoc just greps overs the raw plain text
+of the sources without any C++ preprocessor-like processing.
+CMake in newer versions provides the variables ``CMAKE_AUTOMOC_DEPEND_FILTERS`` (CMake >= 3.9.0)
+and ``CMAKE_AUTOMOC_MACRO_NAMES`` (CMake >= 3.10) to allow the developer to assist automoc.
+
+This macro cares for the explicit setup needed for those variables for common cases of
+C++ preprocessor macros used for Qt-style plugins.
+
+``JSON_NONE`` lists the names of C++ preprocessor macros for Qt-style plugins which do not refer to
+external files with the plugin metadata.
+
+``JSON_ARG1`` lists the names of C++ preprocessor macros for Qt-style plugins where the first argument
+to the macro is the name of the external file with the plugin metadata.
+
+``JSON_ARG2`` is the same as ``JSON_ARG1`` but with the file name being the second argument.
+
+``JSON_ARG3`` is the same as ``JSON_ARG1`` but with the file name being the third argument.
+
+``CONFIG_CODE_VARIABLE`` specifies the name of the variable which will get set as
+value some generated CMake code for instructing automoc for the given macro names,
+as useful in an installed CMake config file. The variable can then be used as usual in
+the template file for such a CMake config file, by ``@<variable_name>@``.
+
+
+Example usage:
+
+Given some plugin-oriented Qt-based software which defines a custom C++ preprocessor
+macro ``EXPORT_MYPLUGIN`` for declaring the central plugin object:
+
+.. code-block:: c++
+
+ #define EXPORT_MYPLUGIN_WITH_JSON(classname, jsonFile) \
+ class classname : public QObject \
+ { \
+ Q_OBJECT \
+ Q_PLUGIN_METADATA(IID "myplugin" FILE jsonFile) \
+ explicit classname() {} \
+ };
+
+In the CMake buildsystem of the library one calls
+
+.. code-block:: cmake
+
+ ecm_setup_qtplugin_macro_names(
+ JSON_ARG2
+ EXPORT_MYPLUGIN_WITH_JSON
+ )
+
+to instruct automoc about the usage of that macro in the sources of the
+library itself.
+
+Given the software installs a library including the header with the macro
+definition and a CMake config file, so 3rd-party can create additional
+plugins by linking against the library, one passes additionally the name of
+a variable which shall be set as value the CMake code needed to instruct
+automoc about the usage of that macro.
+
+.. code-block:: cmake
+
+ ecm_setup_qtplugin_macro_names(
+ JSON_ARG2
+ EXPORT_MYPLUGIN_WITH_JSON
+ CONFIG_CODE_VARIABLE
+ PACKAGE_SETUP_AUTOMOC_VARIABLES
+ )
+
+This variable then is used in the template file (e.g.
+``MyProjectConfig.cmake.in``) for the libary's installed CMake config file
+and that way will ensure that in the 3rd-party plugin's buildsystem
+automoc is instructed as well as needed:
+
+::
+
+ @PACKAGE_SETUP_AUTOMOC_VARIABLES@
+
+Since 5.45.0.
+#]=======================================================================]
+
include(CMakePackageConfigHelpers)
macro(ecm_setup_qtplugin_macro_names)