Overview

Cinema 4D uses CMake to generate projects. But to configure the build settings of a module, it currently still uses projectdefinition.txt files, the build system generator configuration files of the former project generation tool used by the Cinema 4D C++ SDK, the Project Tool. It is possible to switch to a pure CMake setup, see Pure CMake Workflow for details, but project tool files are the recommended way to configure build systems. This manual describes the syntax of projectdefinition.txt files which can be found in the project folder of each module as shown in Fig. I.

+ my_project                           // A Cinema 4D C++ project root.
├── + cmake
├── + frameworks
├── + plugins
│   ├── + my_module                    // A module with its build system configurations.
│   │   ├── + project                  // The build system configuration for the module.
│   │   │   ├── CMakeLists.txt         // A CMake build system configuration.
│   │   │   └── projectdefinition.txt  // A project definition build system configuration.
│   │   ├── + res
│   │   └── + source
├── CMakeLists.txt
├── CMakePresets.json
└── custom_paths.txt                    // An optional custom paths file for the project.

Fig. I: Build system configurations are always placed in the project folder of a module. By default this is done with projectdefinition.txt files. When alternatively a CMakeLists.txt file is provided, it will take precedence over the other configuration type.

Fig. II: Setting up Visual Studio build systems for Cinema 4D projects using CMake.

Migrating Configuration Files

Migrating projects written for the Project Tool will require in most cases no, or only minimal changes, as the CMake setup is largely compatible with Project Tool configurations and uses the same file format, projectdefinition.txt files. When the configuration files of your plugins are relatively simple and similar to what could be found in past SDKs, you very likely will be able to just run CMake without any changes.

In any case, migrating should start by following the Generating Build Systems guide to see if you encounter any errors at all. The following differences exist between Project Tool and the new CMake configurations.

Change	Description
Language Standard	With CMake, the Cinema 4D SDK targets C++ 20, unlike the Project Tool which targeted C++ 17. See C++ Standards for more information.
Solution Definitions	The Project Tool system used a `projectdefinition.txt` file in the modules folder of a project, e.g., in `root/plugins/project/`, to define the modules which shall be loaded. While this file is still shipped with the 2025.2.X SDK, it only exists for legacy Project Tool support. The CMake system either automatically ingests all modules in the path `MAXON_SDK_MODULES_DIR`, which is set by default to `root/plugins`, or reads the `MAXON_CUSTOM_PATHS_FILE` file can contain a list of custom module paths. See Custom Paths for details.
Relative Paths	The Project Tool system could use relative paths to reference files and folders in the project. The CMake system uses absolute paths or path aliases. This means that paths in `projectdefinition.txt` files must be updated to use absolute paths or using path aliases. See General Conventions for details on how path aliases work. This usually only applies in expert projects which use external libraries, header files, or source code that must be included manually. Note Relative paths might still work for some variables in some cases, but it is strongly recommend to use absolute paths or path aliases.
`AdditionalSolutionFiles`	The `AdditionalSolutionFiles` argument in `projectdefinition.txt` files has been deprecated. There is no alternative for this argument in CMake. The major use case for this argument, to include the `natvis` files for the `cinema.framework` and `core.framework`, now has been automated.
`Include.{OS}`	This configuration variable has not been deprecated, but it cannot be used anymore to include header files. Use the build system specific options such as `AdditionalIncludeDirectories`, `HEADER_SEARCH_PATHS`, or `SystemIncludePaths` instead. Warning It is important to understand that a header file included like this will still result in a project that generates and the file showing up in the project explorer of an IDE. But the path where the file is located will no longer be implicitly exposed as a header file search path, e.g., as `AdditionalIncludeDirectories` for Visual Studio. This change is a deliberate decision and not a bug.
`StrictIncludeDirectories`	This configuration variable has been deprecated without a replacement, as `Include.{OS}` is not anymore meant to include header files, i.e., all includes act as if this would be set to `true`.
`FRAMEWORK_SEARCH_PATHS`	This configuration variable has been deprecated without a replacement.

General Conventions

The following conventions are used in projectdefinition.txt files:

Convention	Description
Comments	Comments are marked with `//` and can be placed at the end of a line or on a line by themselves.
Keywords	Configuration variable keywords are case insensitive, e.g., both `C4D=true` and `c4d=true` are valid statements.
Values	Values assigned to a variable are separated by an equal sign, e.g., `FOO = 1`. Warning Values are generally NOT case insensitive.
Boolean Values	Configuration variable that can be either enabled or disabled, can take the values `true` or `false`, e.g., `FOO = true`.
List Values	Many configuration variables accept optionally a list of values separated by a semicolon, e.g., `BAR = 1; 2; 3` is valid just as `BAR = 1` would be. Variables which support this usually show this directly in their example.
Line Concatenations	Overly long lines can be concatenated using the `\` character and a line break.
Postfixes	Many configuration variables support postfixes which allow for specializations by operating system or other factors. E.g., a variable `FOO` which has the specializations `FOO.WIN` and `FOO.LINUX`. These variables are usually documented in the form `FOO.{OS}`, where `.{OS}` or a similar placeholder then indicates that the argument can be specialized. The description will then mention which specializations are supported. The description mentioning the 'empty string' means that the variable can be used without a postfix. E.g., `FOO.{X}` and 'Supports the empty string, `BAR` and `BAZ`' means that `FOO` can be used without a postfix, as `FOO.BAR`, or as `FOO.BAZ`.

Paths

All paths assigned to variables must be absolute paths or use path aliases. Path aliases become relevant in more complex projects which must include external libraries or source code. The average project will likely never have to deal with them. A path alias is denoted by a dollar sign and parentheses, e.g., .

// A variable that takes a path which is defined using an absolute path (but also makes the 
// project inflexible).
INCLUDE.WIN = C:/libs/foo.cpp
 
// A variable that takes a path which is defined using a path alias. Here, the path alias FOO 
// would have to point to `C:/libs/` to have the same effect as the configuration above.
INCLUDE.WIN = $(FOO)/foo.cpp

Projects have access to up to four predefined path aliases:

MAXON_SDK_ROOT_DIR: The root directory of the project, i.e., the folder which contains at least the frameworks and the CMake files of the project. E.g., sdk/.
MAXON_SDK_CURRENT_MODULE_DIR: The module directory from which this alias is invoked. When it is for example invoked from the projectdefinition.txt in sdk/plugins/foo, the path will be sdk/plugins/foo/. It does not matter if this module is inside or outside of MAXON_SDK_ROOT_DIR, i.e., this also works with custom module paths.
MAXON_SDK_EXTERNAL_LIBS_DIR: Points to a centralized folder where external libs are stored. By default this points to sdk/libs/. This alias will be unavailable if the folder does not exist. And project generation will fail if it is used in a project where it is unset.
MAXON_SDK_BUILD_DIR: The root of the current build directory in a project, i.e., the build system which is currently being generated. E.g., sdk/_build_v143/ when generating a Visual Studio 2022 MSVC project. Most users will never need this alias.

Note: All path aliases will be resolved to absolute paths when the build system is generated. This is unavoidable and it is not possible to have build systems using only relative paths when ingesting external dependencies. Simply regenerate the build system when moving a dependency.

Warning: Unlike the other aliases, MAXON_SDK_CURRENT_MODULE_DIR is resolved upon configuration. This means that when one configures a project and then generates it, moves a module using MAXON_SDK_CURRENT_MODULE_DIR, and just regenerates the build system, the result will not work. One must always invoke Configure and Generate in the CMake GUI in such case.

// Points to a `foo.cpp` file in the root of the module this file is located in, e.g., 
// `sdk/plugins/bar.project/libs/foo.cpp` when this line would be in 
// `sdk/plugins/bar.project/project/projectdefinition.txt`.
INCLUDE.WIN = $(MAXON_SDK_CURRENT_MODULE_DIR)/libs/foo.cpp
 
// Points to a `foo.cpp` file in the root of the project, e.g., `sdk/libs/foo.cpp`.
INCLUDE.WIN = $(MAXON_SDK_ROOT_DIR)/foo.cpp
 
// Points to a `foo.cpp` file in the external libs folder of the project, where ever that may be.
INCLUDE.WIN = $(MAXON_SDK_EXTERNAL_LIBS_DIR)/foo.cpp
 
// Points to a `foo.cpp` file in relation to a custom path alias FOO.
INCLUDE.WIN = $(FOO)/foo.cpp

To learn how to define custom path aliases, see Custom Paths.

Custom Paths

By default, the Cinema 4D SDK will include all modules from the MAXON_SDK_MODULES_DIR path, which is set by default to root/plugins. I.e., other than the Project Tool, the CMake SDK will automatically discover and include all modules in a project.

This is the recommended way to include modules. However, it is possible to define custom paths for modules in a text file which is then read by the build system generator to include modules which might not all be located within one root folder. This is done by setting the MAXON_SDK_CUSTOM_PATHS_FILE in the configuration step of CMake. The SDK comes by default with a predefined custom_paths.txt file which can be used as a template or place for such custom path instructions. When such file is provided, and does not provide any module paths, the build system generator will automatically fall back to the MAXON_SDK_MODULES_DIR path. This is because such custom path files can also be used to define path aliases, which can then be used in projectdefinition.txt files.

A custom paths file has a simple syntax, it can define module paths using the MODULE command, path aliases using the ALIAS command, and a new root directory using the ROOTcommand.

# The most common use case is to define module paths using the MODULE command, which will then be 
# included by the CMake build system. All paths in path files can be relative, and the default root 
# directory is MAXON_SDK_ROOT_DIR, i.e., the directory containing at least the frameworks and 
# CMake files. Setting module paths in this manner will disable to auto-including behavior of the
# MAXON_SDK_MODULES_DIR variable. This however only does apply when the custom paths file does 
# actually set any modules. A custom paths files which sets no modules can still be used in 
# conjunction with the auto-including behavior of MAXON_SDK_MODULES_DIR.
 
# Include the five modules included in the SDK by default, in relation to the default ROOT 
# directory MAXON_SDK_ROOT_DIR.
MODULE plugins/example.assets
MODULE plugins/example.image
MODULE plugins/example.main
MODULE plugins/example.migration_2024
MODULE plugins/example.nodes
 
# All path commands can also use absolute paths and modules can be included from anywhere. The 
# latter of the two paths could be for macOS or Linux, the former for Windows.
MODULE d:/projects/cinema/foo_plugin
# MODULE ~/documents/code/bar_plugin
 
# A new root directory in relation to which relative paths are set can be overwritten using
# the ROOT command. It will apply until it is overwritten by a new root command.
ROOT d:/projects/cinema
 
# This module would then be included from the d:/projects/cinema/ directory.
MODULE baz_plugin
 
# Path files can also define path aliases using the ALIAS command. Path aliases can then later be 
# used in projectdefinition.txt files. FOO would be an alias for `d:/projects/cinema/libs` and BAR 
# would be an alias for `c:/libs`. Aliases are only meant to be used for directories and not for
# individual files.
ALIAS FOO libs
ALIAS BAR c:/libs

Common Settings

Describes commonly used arguments in projectdefinition.txt files. Most users will only need these arguments.

Argument	Description
`Platform`	Defines the platforms for which this module shall be built, can take the values `Win64`, `OSX`, and `Linux`. `Platform=Win64;OSX;Linux`
`Type`	Defines the type of the module, can take the values `DLL` (usually used for plugins/modules) or `Lib` (usually used for framework). `Type=DLL`
`APIS`	Defines the frameworks that are accessible for the source code of this module. `APIS=cinema.framework;core.framework`
`C4D`	Must be set when the `cinema` and the `core` framework are both being included. Effectively sets the preprocessor define `USE_API_MAXON`. Can be either `true` or `false`. `C4D=true` Warning Will also disable style checks and should be followed by a command which re-enables them as for example `stylecheck.level=3`.
`stylecheck.level`	Defines the rigidity of style checks in the file, where `0` are no checks and `3` is the highest rigidity. Also re-enables style checks when they have been disabled before. `stylecheck.level=3`
`ModuleId`	Defines the ID with which a module attempts to register with Cinema 4D. Modules which fail to register will not be loaded and its plugins will therefore neither register nor load. `ModuleId=com.mycompany.modules.foo` Warning Must be a unique identifier in reverse domain name notation derived from a web-domain you own, e.g., `com.mycompany.mymodule`. Do not use module IDs that start with `net.maxon.` as your module will not load otherwise. Use only lower case letters, numbers, the underscore character, and the dot character for IDs. Do not use web domains as a prefix you do not own. Note When you do not own any web domains, register a plugin ID and use the pattern `user.{name}{pid}...`, e.g., `user.alice123456789.module.foo`, where `user.alice123456789` would be then the permanent prefix used for all module and registry registrations.

Example:

This file could be the projectdefinition.txt of a 'foo' module in a project. The file would be located in foo.plugin/project. The plugin would be compiled into a binary named after the module, i.e., foo.plugin.xdl64 for a Visual Studio MSVC project.

// The supported platforms for the module
Platform=Win64;OSX;Linux
 
// The type of the module, for plugins this will be DLL.
Type=DLL
 
// The frameworks that can be used by this module. Not including a framework here means that source
// files of this module will not be able to include files from such non-included framework. The three
// frameworks shown here are a good baseline for most plugin modules.
APIS=\
    cinema.framework; \
    cinema_hybrid.framework; \
    core.framework
 
// Must be set in all modules that use both the cinema.framework and the core.framework. Also disables
// all style checks in this module. One must re-enable style checks after setting this argument when 
// the source processor shall style check code (which is strongly recommended).
C4D=true
 
// Set the style check rigidity, and by that re-enable style checks.
stylecheck.level=3
 
// The resulting plugin binary will attempt to register this module with the here given module ID
// with Cinema 4D on startup. This ID must be unique and follow the inverted company domain pattern.
// DO NOT use module IDs that lie in the 'net.maxon...' domain, as your plugin will not load otherwise.
ModuleId=com.company.plugins.foo

In- and Exclude Settings

Describes settings with which files and folders outside of the module source folder can be included and how files and folders inside source can be excluded. CMake will automatically include all the files in the source folder of the module.

Warning: Other than for the Project Tool, Include.{OS} can no longer be used to include header files. See also Migrating Configuration Files for details.

Argument	Description
`Include.{platform}`	Manually includes files or folders from outside of the `source` directory to the Visual Studio, Xcode, or GCC project. Possible values for the `{platform}` are `Win`, `OSX`, and `Linux`. `Include=c:/code/libs/someclass.cpp; c:/code/libs/otherClass.cpp;`
`Exclude.{platform}`	Manually excludes files or folders from the Visual Studio, Xcode, or GCC project. Possible values for the `{platform}` are `Win`, `OSX`, and `Linux`. `Exclude.OSX=source/libs/win_impl.cpp; source/libs/win_impl.h;`
`ExcludeFromBuild.{platform}`	Manually excludes files or folders from the build process but not from the Visual Studio, or Xcode project. Does not support `Linux`. Possible values for the `{platform}` are `Win` and `OSX`. `ExcludeFromBuild=c:/code/source/lnx_impl.h; c:/code/source/osx_impl.h;`

Example:

// The following cpp files in a /libs/ folder in the root of this module should be 
// included for all platforms.
Include = $(MAXON_SDK_CURRENT_MODULE_DIR)/libs/someClass.cpp;\
          $(MAXON_SDK_CURRENT_MODULE_DIR)/libs/otherClass.cpp;
 
// The following files in the global external libs directory should be added only to  
// the code project.
Include.OSX = $(MAXON_SDK_EXTERNAL_LIBS_DIR)/mac_foo_impl.cpp;\
              $(MAXON_SDK_EXTERNAL_LIBS_DIR)/mac_bar_impl.cpp;
 
// Exclude the following files from the natively discovered source files of the module 
// on the respective platforms.
Exclude.Win = $(MAXON_SDK_CURRENT_MODULE_DIR)/source/mac_impl.cpp
Exclude.OSX = $(MAXON_SDK_CURRENT_MODULE_DIR)/source/win_impl.cpp

Windows Specific Settings

Describes settings which only apply to Visual Studio build systems.

Argument	Description
`AdditionalLibraryDirectories.{target}`	Defines search paths for additional library binaries. Possible targets are the empty string, `Debug`, and `Release`. `AdditionalLibraryDirectories=c:/code/libs/bin`
`AdditionalIncludeDirectories`	Defines search paths for additional library header files. `AdditionalIncludeDirectories=c:/code/libs/include`
`AdditionalDependencies.{target}`	Defines libraries found in the search paths to link against. Possible targets are the empty string, `Debug`, and `Release`. `AdditionalDependencies=foo.lib; bar.lib`
`AdditionalCompileOptions.Win64`	Defines additional compiler options. `AdditionalCompileOptions.Win64=/w`
`AdditionalLinkOptions`	Defines additional linker options, internally exclusively used to ignore specific warnings. `AdditionalLinkOptions=/ignore:4006,4221`
`AdditionalPreprocessorDefinitions.Win`	Defines additional preprocessor definitions only exposed to Windows builds. `AdditionalPreprocessorDefinitions.Win=MY_DEFINE;ANOTHER_DEFINE`
`DisableSpecificWarnings.Win64`	Disables specific compiler warnings (which also means they cannot be elevated to errors anymore). `DisableSpecificWarnings.Win64=4018;4068;4242`
`SUBSYSTEMCONSOLE`	Sets the Windows subsystem to `CONSOLE` for developing a console/terminal app. Mostly useless in the context of the SDK. `SUBSYSTEMCONSOLE=true`
`IGNORESPECIFICDEFAULTLIBRARIES.{TARGET}`	Sets the Visual Studio linker setting of the same name to ignore default libraries. `IgnoreSpecificDefaultLibraries=LIBCMT`
`CLANG_WARN_DOCUMENTATION_COMMENTS`	Enables or disables warnings for missing or incorrect documentation comments in the source code. Only works when the compiler is Clang. `CLANG_WARN_DOCUMENTATION_COMMENTS=NO` Warning This argument is an outlier, as it scans for 'NO' instead of 'true' or 'false'.
`PreBuildEvent`	Defines a pre-build event, usually a script that should be run. `PreBuildEvent = call python c:/code/scripts/prebuild_event.py`

Note: The Visual Studio setting AdditionalSolutionFiles has been deprecated since there are no solution projectdefinition.txt files anymore.

Example:

// This is the typical way to include a library in Visual Studio. We first define the binary search 
// paths, then the binaries to link against, and finally the header file search paths for these 
// binaries.
AdditionalLibraryDirectories=\
    $(MAXON_SDK_CURRENT_MODULE_DIR)/libs/bin; \
    $(MAXON_SDK_EXTERNAL_LIBS_DIR)/bin
AdditionalDependencies.Debug=\
    some_debug.lib;\
    other_debug.lib;\
AdditionalDependencies.Release=\
    some_release.lib;\
    other_release.lib;\
AdditionalIncludeDirectories=\
    $(MAXON_SDK_CURRENT_MODULE_DIR)/libs/include; \
    $(MAXON_SDK_EXTERNAL_LIBS_DIR)/include
 
// Ignore warnings for a variable of an inner scope shadowing a variable of an outer scope.
AdditionalCompileOptions.Win64=/wd"4456"
 
// Disable warnings for unsigned/singed comparisons, unused functions, and unreachable code.
DisableSpecificWarnings.Win64=4018;4068;4242;
 
// Define a pre-build event which invokes a Python script located in the module's scripts folder.
PreBuildEvent = call python $(MAXON_SDK_CURRENT_MODULE_DIR)/scripts/prebuild_event.py

macOS Specific Settings

Describes settings which only apply to Xcode build systems.

Argument	Description
`FRAMEWORKS.OSX`	Adds the header files and library link targets of a macOS framework to the project. `FRAMEWORKS.OSX=/System/Library/Frameworks/Metal.framework;`
`HEADER_SEARCH_PATHS`	Defines search paths for additional library header files to be included as `#include <...>`. `HEADER_SEARCH_PATHS=/System/includes`
`USER_HEADER_SEARCH_PATHS`	Defines search paths for additional library header files to be included as `#include "...".` `USER_HEADER_SEARCH_PATHS=c:/code/libs/include`
`OTHER_LDFLAGS.{target}`	Defines libraries to link against. This can also be used to set other linker options, but defining library targets is the main purpose. Other than under Windows and Linux, linking against libraries is not split into two options of defining search paths and then the link files. Possible targets are the empty string, `DEBUG` and `RELEASE`. `OTHER_LDFLAGS = -lbz2;-liconv;-lz;`
`AdditionalPreprocessorDefinitions.OSX`	Defines additional preprocessor definitions only exposed to macOS builds. `AdditionalPreprocessorDefinitions.OSX=MY_DEFINE;ANOTHER_DEFINE`
`DisableSpecificWarnings.OSX`	Disables specific compiler warnings (which also means they cannot be elevated to errors anymore). `DisableSpecificWarnings.OSX=4018;4068;4242`
`SHELLSCRIPT.OSX`	Defines the content (not the path) of a shell script executed before the build event. Conventionally used to invoke a Python script. `SHELLSCRIPT.OSX = python3 c:/code/scripts/prebuilt_action.py`
`CLANG_WARN_DOCUMENTATION_COMMENTS`	Enables or disables warnings for missing or incorrect documentation comments in the source code. `CLANG_WARN_DOCUMENTATION_COMMENTS=NO` Warning This argument is an outlier, as it scans for 'NO' instead of 'true' or 'false'.

Example:

// Include the metal framework with this project.
Frameworks.OSX = $(SYSTEM)/Library/Frameworks/Metal.framework 
 
// Link against a library for all configs, and enforce unused code being stripped from release builds.
OTHER_LDFLAGS=$(MAXON_SDK_CURRENT_MODULE_DIR)/libs/bin/libfoo.a
OTHER_LDFLAGS.RELEASE=-dead_strip
 
// Define a search path for library header files.
USER_HEADER_SEARCH_PATHS=$(MAXON_SDK_CURRENT_MODULE_DIR)/libs/include
 
// Create a 'foo' directory in 'Home', copy a file into that dir, and then invoke a Python script.
SHELLSCRIPT.OSX = mkdir -p ~/foo && cp -f $(MAXON_SDK_CURRENT_MODULE_DIR)/misc/somefile.bar && \
                        python $(MAXON_SDK_CURRENT_MODULE_DIR)/scripts/prebuilt_action.py ~/foo
 
// Disable warnings for unsigned/singed comparisons, unused functions, and unreachable code.
DisableSpecificWarnings.OSX=4018;4068;4242;

Linux Specific Settings

Describes settings which only apply to Linux build systems.

Argument	Description
`LibrarySearchPath`	Defines search paths for additional library binaries. `LibrarySearchPath=/usr/lib/x86_64-linux-gnu; /usr/lib/tinyxml`
`SystemIncludePaths`	Defines search paths for additional library header files. `SystemIncludePaths=/usr/include/gtk-3.0/; /usr/include/tinyxml/`
`Libraries`	Defines dynamic libraries found in the search paths to link against. `Libraries=gtk-3;`
`StaticLibraries.Linux`	Defines static libraries found in the search paths to link against. `StaticLibraries.Linux=tinyxml`
`AdditionalPreprocessorDefinitions.Linux`	Defines additional preprocessor definitions only exposed to Linux builds. `AdditionalPreprocessorDefinitions.Linux=MY_DEFINE;ANOTHER_DEFINE`

Example:

// Define search paths for additional library binaries and header files.
LibrarySearchPath=/usr/lib/x86_64-linux-gnu; /usr/lib/tinyxml
SystemIncludePaths=/usr/include/gtk-3.0/; /usr/include/tinyxml/
 
// Link against a dynamic library and a static library.
Libraries=gtk-3;
StaticLibraries.Linux=tinyxml
 
// Define additional preprocessor definitions.
AdditionalPreprocessorDefinitions.Linux=MY_DEFINE;ANOTHER_DEFINE

Misc Settings

Describes settings which apply to all build systems but are of more expert or niche nature.

Argument	Description
`AdditionalPreprocessorDefinitions`	Defines additional preprocessor definitions, which are exposed to all build systems. `AdditionalPreprocessorDefinitions=MY_DEFINE;ANOTHER_DEFINE`
`ExceptionHandling`	Enables or disables the compiler specific exception handling. `ExceptionHandling=true` Note Cinema 4D projects conventionally do not use exception handling and instead use their own error system.
`maxon`	Marks a module/framework as provided by Maxon Computer when set to true. `maxon=true` Warning Must never be used by third parties.
`OmitApiDefine`	Enables or disables (when set to true) defining the `MAXON_API` preprocessor define for frameworks. Technically related to the `C4D` argument (which sets `USE_API_MAXON`) but of very rare use. `OmitApiDefine=true`
`publicframework`	Marks a framework as public and therefore shipped with the SDK when set to true. Conventionally only defined in public frameworks and completely omitted (and therefore implicitly false) on frameworks which are private. `publicframework=true`
`RuntimeTypeInfo`	Enables or disables the compiler specific Run-Time Type Information (RTTI) support. `RuntimeTypeInfo=true`

Style Check Settings

Describes settings which control style checks enforced at compilation time.

The settings described here are irrelevant for the build system - CMake will just ignore them - and instead read by the Source Processor and enforced when a module is being built. It is recommend to follow Maxon code style in projects and therefore leave these settings at their default and to use stylecheck.level=3.

Note: By default all checks are enabled. Style check levels can be used to enable or disable style checks in bulk.; The settings are processed from top to bottom. A later setting can overwrite a previous one.

Certain checks can be disabled in code using these macros:

MAXON_WARN_MUTE_FUNCTION_LENGTH: Disables function length check.
MAXON_WARN_MUTE_NAMING: Disables function naming scheme check.

General Settings

Argument	Description
`stylecheck.level`	Defines the rigidity of style checks in the file, where `0` are no checks and `3` is the highest rigidity. Also re-enables style checks when they have been disabled before. `stylecheck.level = 3`
`stylecheck`	Enables or disables style checks. `stylecheck = false`
`stylecheck.aswarnings`	Turns style errors into warnings and by that allow compilation to continue. `stylecheck.aswarnings = true`
`stylecheck.domains`	Checks identifiers in registration calls such as `MAXON_COMPONENT_CLASS_REGISTER` for having one of the provided prefixes. Prefixes must be separated with a semicolon. For the given example, the ID `com.mycompany.baz.stuff` would fail, but `com.mycompany.bar.stuff` would not. `stylecheck.domains = com.mycompany.foo; com.mycompany.bar`
`stylecheck.register-qualifiers`	Registers custom qualifiers used in function declarations with the source processor, such as `FOO` and `BAR` in `FOO bool Run() BAR;`. Note that the symbols must still be declared and defined in normal C++ code, this feature only allows to the source processor to correctly parse such code. See Support for Custom Qualifiers for details. `stylecheck.register-qualifiers = FOO; BAR`

Level 1 Settings

These settings will be enabled when the style check level is set to one.

Argument	Description
`stylecheck.whitespace`	Checks for missing whitespaces in expressions, for example the missing whitespace after the `if` in `if(condition)`. `stylecheck.whitespace = true`
`stylecheck.indentation`	Checks for correct indentation, as for example top-level members of a namespace scope being indented. `stylecheck.indentation = true`
`stylecheck.todo`	Checks the formatting of TODO comments. A `TODO` must follow the form `// TODO: (NAME) MESSAGE` where `NAME` is a singular word, e.g., `// TODO: (Alice) I like muffins, we need more muffins.` `stylecheck.todo = false`
`stylecheck.case-break`	Checks `switch` cases for having a `break` statement at their end (or `MAXON_SWITCH_FALLTHROUGH`). `stylecheck.case-break = true`
`stylecheck.virtual`	Checks framework modules for containing illegal virtual function declarations in frameworks. This option is not absolute, frameworks which start with `private_` are not tested, and so are the `core`, `kernel`, `cinema`, `cinema_legacy`, and `cinema_maxon` framework. `stylecheck.virtual = true`
`stylecheck.static-within-type`	Checks for declarations such as `const static Int x = 0;` which should be written as `static const Int x = 0;`. `stylecheck.static-within-type = true`
`stylecheck.supercall`	Warns when the implementation of `IsEqual`, `Compare`, or `GetHashCodeImpl` of an `ObjectInterface` component does not use `super` when deferring to the base implementation. E.g., will trigger on `MAXON_METHOD Bool IsEqual(const ObjectInterface* other) const { return IsEqual(other); }`. `stylecheck.supercall = true`

Level 2 Settings

These settings will be enabled when the style check level is set to two.

Argument	Description
`stylecheck.no-whitespace`	Checks for forbidden whitespaces, as for example the extra whitespace after and before the parenthesis in `if ( condition )`. `stylecheck.no-whitespace = true`
`stylecheck.consistent-blocks`	Checks statements which can be explicitly scoped such as `if` and `switch` for being consistently scoped or not. Having for example an `if` with no explicit scope, but its `else` having one, would trigger this check; e.g.: `if (foo) return 1; else { return 2; }` `stylecheck.consistent-blocks = true`
`stylecheck.newline-for-substatement`	Checks the sub-statements of `if` or loop expressions for being on a new line. E.g., `if (foo) i++;` would trigger this, as there is no line break between the condition and the statement. `stylecheck.newline-for-substatement = true`
`stylecheck.explicit`	Checks that constructors which can be used as conversion constructors are marked by either `explicit` or `MAXON_IMPLICIT`. `stylecheck.explicit = true`

Level 3 Settings

These settings will be enabled when the style check level is set to three.

Argument	Description
`stylecheck.typedef-struct`	Checks for C-style struct declarations being used such as `typedef struct { ... } S;`. Using such declarations is not allowed. `stylecheck.typedef-struct = true`
`stylecheck.enum-class`	Checks that scoped enums are used; use `enum class` instead of just `enum`. `stylecheck.enum-class = true`
`stylecheck.enum-registration`	Checks that enums end with one of the enum macros (`MAXON_ENUM_LIST` etc.). `stylecheck.enum-registration = true`
`stylecheck.class-for-templateparam`	Checks that a template type parameters are specified with `typename` instead of `class`. E.g., `template <typename T>` instead of `template <class T>`. `stylecheck.class-for-templateparam = true`
`stylecheck.void-paramlist`	Checks for C-style function declarations with empty parameter list such as `void Func(void);`. `stylecheck.void-paramlist = true`
`stylecheck.max-linecount`	Sets the maximum line count a function may have. The default value is `600`. `stylecheck.max-linecount = 600` Warning The style guide maximum length of a function is still `500` lines.
`stylecheck.naming`	Checks the name of entities, enforces camel-case for functions and types, and global variables starting with `g_`. E.g., a function must be named `void FooBar();` and a global variable must be named `Int32 g_foo_bar;`. See also Style Guide: Naming. `stylecheck.naming = true`

Pure CMake Workflow

The pure CMake workflow allows you to use CMakeLists.txt files instead of projectdefinition.txt to configure modules. It is however not sensibly possibly to write such CMakeLists.txt per hand, instead one must copy files from a build system. The general workflow is:

Configure a project using projectdefinition.txt files.
Generate a build system for that project.
Copy the CMakeLists.txt files generated for the project into the project.
Modify these CMakeLists.txt files to take advantage of a pure CMake setup.

Warning: Other than for projectdefinition.txt files, there is no guarantee that variable and function names used in CMakeLists.txt files will stay the same across multiple versions of Cinema 4D. We will not announce changes in our internal CMake setup. Using a pure CMake setup is therefore not recommended for most plugin developers, as such files must be maintained to stay compatible with the Cinema 4D SDK.

+ my_project
├── + _build_v143
│   └── + plugins                             // The configurations for the modules of the project.
│   │   └── + my_module
│   │       └── + project
│   │            └── CMakeLists.txt           // The configuration of my_module converted into a `CMakeLists.txt`
├── + cmake
├── + frameworks
├── + plugins
│   ├── + my_module
│   │   ├── + project
│   │   │   └── projectdefinition.txt         // The native `projectdefinition.txt` configuration for the module.
│   │   ├── + res
│   │   └── + source
├── CMakeLists.txt
├── CMakePresets.json
└── sdk_modules.txt

Fig. II: Generating a build system once will convert all projectdefinition.txt configurations into CMakeLists.txt files in the build system. Which can then be copied back into the project folder of a module to be modified and used in place of the projectdefinition.txt file. Here we would have to copy the CMakeLists.txt file from my_project\_build_v143\plugins\my_module\project to my_project\plugins\my_module\project.

Note: These CMakeLists.txt files although sourced from a specific build system, will be build system agnostic, just as the projectdefinition.txt files they have been derived from.

Table of Contents