EBN extra-cmake-modules comments spelling cleanup

Summary: Correct spelling in extra-cmake-modules comments.

Reviewers: apol

Reviewed By: apol

Subscribers: kde-frameworks-devel, kde-buildsystem

Tags: #frameworks, #build_system

Differential Revision: https://phabricator.kde.org/D25752

4 files changed, 18 insertions, 18 deletions

diff --git a/find-modules/rules_engine.py b/find-modules/rules_engine.py
index 25c65a59..88cb2777 100755
--- a/find-modules/rules_engine.py
+++ b/find-modules/rules_engine.py
@@ -167,9 +167,9 @@ class ContainerRuleDb(AbstractCompiledRuleDb):
     """
     THE RULES FOR CONTAINERS.
 
-    These are used to customise the behaviour of the SIP generator by allowing
+    These are used to customize the behaviour of the SIP generator by allowing
     the declaration for any container (class, namespace, struct, union) to be
-    customised, for example to add SIP compiler annotations.
+    customized, for example to add SIP compiler annotations.
 
     Each entry in the raw rule database must be a list with members as follows:
 
@@ -242,9 +242,9 @@ class ForwardDeclarationRuleDb(AbstractCompiledRuleDb):
     """
     THE RULES FOR FORWARD DECLARATIONS.
 
-    These are used to customise the behaviour of the SIP generator by allowing
+    These are used to customize the behaviour of the SIP generator by allowing
     the forward declaration for any container (class, struct, union) to be
-    customised, for example to add SIP compiler annotations.
+    customized, for example to add SIP compiler annotations.
 
     Each entry in the raw rule database must be a list with members as follows:
 
@@ -307,8 +307,8 @@ class FunctionRuleDb(AbstractCompiledRuleDb):
     """
     THE RULES FOR FUNCTIONS.
 
-    These are used to customise the behaviour of the SIP generator by allowing
-    the declaration for any function to be customised, for example to add SIP
+    These are used to customize the behaviour of the SIP generator by allowing
+    the declaration for any function to be customized, for example to add SIP
     compiler annotations.
 
     Each entry in the raw rule database must be a list with members as follows:
@@ -385,8 +385,8 @@ class ParameterRuleDb(AbstractCompiledRuleDb):
     """
     THE RULES FOR FUNCTION PARAMETERS.
 
-    These are used to customise the behaviour of the SIP generator by allowing
-    the declaration for any parameter in any function to be customised, for
+    These are used to customize the behaviour of the SIP generator by allowing
+    the declaration for any parameter in any function to be customized, for
     example to add SIP compiler annotations.
 
     Each entry in the raw rule database must be a list with members as follows:
@@ -461,8 +461,8 @@ class TypedefRuleDb(AbstractCompiledRuleDb):
     """
     THE RULES FOR TYPEDEFS.
 
-    These are used to customise the behaviour of the SIP generator by allowing
-    the declaration for any typedef to be customised, for example to add SIP
+    These are used to customize the behaviour of the SIP generator by allowing
+    the declaration for any typedef to be customized, for example to add SIP
     compiler annotations.
 
     Each entry in the raw rule database must be a list with members as follows:
@@ -523,8 +523,8 @@ class VariableRuleDb(AbstractCompiledRuleDb):
     """
     THE RULES FOR VARIABLES.
 
-    These are used to customise the behaviour of the SIP generator by allowing
-    the declaration for any variable to be customised, for example to add SIP
+    These are used to customize the behaviour of the SIP generator by allowing
+    the declaration for any variable to be customized, for example to add SIP
     compiler annotations.
 
     Each entry in the raw rule database must be a list with members as follows:
@@ -643,7 +643,7 @@ class MethodCodeDb(AbstractCompiledCodeDb):
     THE RULES FOR INJECTING METHOD-RELATED CODE (such as %MethodCode,
     %VirtualCatcherCode, %VirtualCallCode and other method-level directives).
 
-    These are used to customise the behaviour of the SIP generator by allowing
+    These are used to customize the behaviour of the SIP generator by allowing
     method-level code injection.
 
     The raw rule database must be an outer dictionary as follows:
@@ -748,7 +748,7 @@ class ModuleCodeDb(AbstractCompiledCodeDb):
     THE RULES FOR INJECTING MODULE-RELATED CODE (such as %ExportedHeaderCode,
     %ModuleCode, %ModuleHeaderCode or other module-level directives).
 
-    These are used to customise the behaviour of the SIP generator by allowing
+    These are used to customize the behaviour of the SIP generator by allowing
     module-level code injection.
 
     The raw rule database must be a dictionary as follows:
diff --git a/find-modules/sip_generator.py b/find-modules/sip_generator.py
index 20e55ce8..b521e6c6 100644
--- a/find-modules/sip_generator.py
+++ b/find-modules/sip_generator.py
@@ -770,7 +770,7 @@ def main(argv=None):
     """
     Take a single C++ header file and generate the corresponding SIP file.
     Beyond simple generation of the SIP file from the corresponding C++
-    header file, a set of rules can be used to customise the generated
+    header file, a set of rules can be used to customize the generated
     SIP file.
 
     Examples:
diff --git a/modules/ECMGenerateExportHeader.cmake b/modules/ECMGenerateExportHeader.cmake
index 7de9aa69..52dd29d4 100644
--- a/modules/ECMGenerateExportHeader.cmake
+++ b/modules/ECMGenerateExportHeader.cmake
@@ -138,7 +138,7 @@
 #
 # When the ``GROUP_BASE_NAME`` has been used, the same macros but with the
 # given ``<group_base_name>`` prefix are available to define the defaults of
-# these macros, if not explicitely set.
+# these macros, if not explicitly set.
 #
 # Note: The tricks applied here for hiding deprecated API to the compiler
 # when building against a library do not work for all deprecated API:
@@ -302,7 +302,7 @@
 # When using the ``NO_DEFINITION_EXPORT_TO_BUILD_INTERFACE`` and the project
 # for the "Foo" library includes also tests and examples linking against the
 # library and using deprecated API (like tests covering it), one better
-# explicitely sets ``FOO_DISABLE_DEPRECATED_BEFORE_AND_AT`` for those targets
+# explicitly sets ``FOO_DISABLE_DEPRECATED_BEFORE_AND_AT`` for those targets
 # to the version before and at which all deprecated API has been excluded from
 # the build.
 # Even more when building against other libraries from the same group "Bar" and
diff --git a/tests/ECMGenerateExportHeaderTest/CMakeLists.txt b/tests/ECMGenerateExportHeaderTest/CMakeLists.txt
index 5b25a7df..45ad611e 100644
--- a/tests/ECMGenerateExportHeaderTest/CMakeLists.txt
+++ b/tests/ECMGenerateExportHeaderTest/CMakeLists.txt
@@ -102,7 +102,7 @@ foreach(_group_test_mode ${group_test_modes})
     foreach(_exclude_index RANGE ${_last_index})
         list(GET library_versions ${_exclude_index} _exclude_deprecated_before_and_at)
         # using disabled API limit below the excluded API limit is not supported and
-        # catched by the code generated from the ecm_generate_export_header,
+        # caught by the code generated from the ecm_generate_export_header,
         # so testing those combination will not work, so start from the excluded API limit
         foreach(_disable_index RANGE ${_exclude_index} ${_last_index})
             list(GET library_versions ${_disable_index} _disable_deprecated_before_and_at)