Project management for C4D SDK projects

Havremunken

Hi there,
This is a question to the community of C4D developers as much as to the Maxon guys. I would love to get some feedback and/or discussion on some questions and topics that relate to C4D project management more than the actual SDK itself.

I'm coming from a background of C# development - so I spend my day job in Visual Studio 2022 as it is, and have not regularly used C++ daily for many years, but I am relearning for a C4D plugin project I am doing. This context affects some of my perspectives.

How are you typically doing source control for your project? In my case, git is used for more or less everything I do, and I will use that to keep track of this project as well. Do you usually put the whole sdk folder in there, or just the folder for your project in sdk/plugins? If you work on multiple different projects at one time, does this change how you approach source control? For instance, do you have multiple sdk folders with one project each, or do you put multiple projects in the same plugin folder and keep them in separate git repositories? Or do you simply have one large über-git-repo?
Slightly related to the above - if you support multiple different Cinema 4D versions, how do you do that? Multiple sdk folders (per version), same plugin code base with compiler directives to handle C4D version differences as necessary? I would think supporting different versions would be an argument for keeping only the plugin code in git, but I would love to get perspectives from people with more experience than me in this matter.
I would like to do some unit testing using Google Test in my project. I know about the C4D unit testing support and will probably use that too for stuff that needs to touch C4D. However, for my own code that is just plain C++ code, I would like to get immediate feedback in VS / ReSharper each time I compile. I can probably run all my unit tests a hundered times in the time it takes to start C4D once. However, keeping this in a separate project like I am used to from dotnet was a bad idea - when I needed to re-run the Project Tool, it killed and removed my test project. Another option is to include the test code in my actual plugin project and make sure the test code is stripped out when I do a release build. Anyone else done something similar and want to share their experience?
Another thing the Project Tool does when it runs is to basically overwrite the entire structure of my project. From dotnet I am used to creating folders in my solution (mapped to actual folders on disk) to keep related code together, and not to end up with one big mess of a thousand source files. When I did C++ last, Visual Studio wasn't invented yet, so I don't know how to do the same thing there - the concept of (disk) folders seems not to exist. To keep a minimum of organization I used the feature known as "Filters" to create virtual folders in my project. That works fine, but the Project Tool just kills this structure and I am back to one big folder of source files. I don't NEED to split my code into file-per-class or anything like that, but it helps me wrap my brain around things. How do people go about keeping their projects somewhat organized?

Any input on any of these points is welcome - I am learning here, and if anyone is willing to share their experiences, I am sure that can be useful to other users too.

Thanks in advance for any opinions, facts or other comments on these topics!

Havremunken

One further point I wanted to ask about; At this early stage of building my plugin, I run C4D in the VS debugger a lot; If someone wasn't aware, you can actually change your plugin code while Cinema 4D is running and "hot compile/reload" (Alt+F10) changes without restarting C4D - huge time-saver!

I do use ApplicationOutput() and DiagnosticOutput() for some things to check that my computations are correct. However, some times it is very useful to see things in the VS debugger as well. Is there a way of seeing the contents of a maxon::String in the VS debugger? I have tried but I can not find anything in the Watch-window or any other way. Since my plugin is dealing with a lot of string value manipulation, it would be very good to see the contents directly in the debugger; Especially since when you hit a breakpoint and look through your code, you can not easily go back to the C4D window (to see output) without resuming the application.

m_adam

Hi @Havremunken, first of all please try to split your question into several topic, this way it's easier to have a precise discussion on a topic.
So if you have any follow-up from my reply please open a new topic so we can properly track it down.
Moreover I moved your topic to general discussion since most of them question are not directly related to the C4D API but rather general good development practice.

I will let the community answers, but IMHO git is the way to go, with a gitignore over all dynamically generated files. But it's true that a minimal gitignore could be provided within the sdk so at least you have a base. Generally this includes all files generated by the source processor (*.hxx) files and solution/project files.
I will see what we can do for future releases.
There is no official way of doing that, the best way is to check for the API_VERSION and then branch accordingly.
Here maybe the best things would be to make 2 splitted project, one that is pure C++ and that generate a dll that you will link with the Cinema 4D plugin.
This way you could run the google unittest on your own project.
The project tool is like cmake, its a project generation tool that reflect the directory structure of the filesystem. So if you want a folder in the IDE create a folder in your file system and run the project tool.

Regarding String visualisation in debugger, we provide natvis file for exactly this purpose for more information please look at https://developers.maxon.net/docs/cpp/2024_2_0/page_maxonapi_dev_windows.html#page_maxonapi_dev_windows_env

Cheers,
Maxime

Havremunken

Thank you very much, Maxime! I'll check out the various points and open a dedicated thread if I have anything further to ask or say about these topics.