SDK Documentation
-
On 01/10/2014 at 17:02, xxxxxxxx wrote:
Can someone please tell me the differences between the Debug/Release/Intel and the LibDebug/LibRelease/LibIntel configurations in the VisualStudio project for the cinema framework?
-
On 01/10/2014 at 19:31, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Can someone please tell me the differences between the Debug/Release/Intel and the LibDebug/LibRelease/LibIntel configurations in the VisualStudio project for the cinema framework?
The framework is build in the Cinema 4D project build and requires these configurations.
The intel compiler is used to produce the final build of C4D. There is no debug build under Intel.
Which one we use depends of our needs...for DLL builds - dynamic library
Debug - visual studio debug build (DLL)
Release - visual studio release build (DLL)
Intel - Intel compiler release build (DLL)Library builds - static library, included in a project (which may be a DLL itself, or an executable)
LibDebug - visual studio debug build (library)
LibRelease - visual studio release build (library)
LibIntel - visual studio release build (library)Can I ask why you you are asking?
-
On 02/10/2014 at 06:59, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Originally posted by xxxxxxxx
Can someone please tell me the differences between the Debug/Release/Intel and the LibDebug/LibRelease/LibIntel configurations in the VisualStudio project for the cinema framework?
The framework is build in the Cinema 4D project build and requires these configurations.
The intel compiler is used to produce the final build of C4D. There is no debug build under Intel.
Which one we use depends of our needs...Yeah, what "Debug", "Release" and "Intel" is for, was clear so far of course. !
Wink[URL-REMOVED]
My question was just related to the "Lib..." part in the configs.
The difference of the respective configs with the "Lib" and without the "Lib" in the name.According to your explanation that would mean the one group is for creating dynamic and the other one for creating static libraries.
Thank you for answering that so far.
Originally posted by xxxxxxxx
Can I ask why you you are asking?
I asked because I was unsure which config to choose for compiling my plugins.
I precompiled all the x64 versions of the c4d api (cinema.framework) for the VS compiler, so that I could link them directly to my plugins without the need to rebuild the framework again and again everytime I compile or recompile some of my own code.
And all produced (I guess) static libraries:
x64_Debug: cinema.framework_Debug_64bit.lib
x64_Release: cinema.framework_Release_64bit.lib
x64_LibDebug: cinema.framework_LibDebug_64bit.lib
x64_LibRelease: cinema.framework_LibRelease_64bit.libSo I was (and in fact still am) unsure which one to use.
I guess it would have to be the "Lib..."-variations for the cinema.framework (x64_LibRelease & x64_LibDebug) and the other ones (x64_Release & x64_Debug) for the plugins itself as they have to be dynamic. (I mean, *.cdl and *.cdl64 are in fact simple *.dll's, only renamed)
But it seems like "cinema.framework_Release_64bit.lib" (and "cinema.framework_Debug_64bit.lib") would also work instead. And in fact they would have been even my first choice so far.
That's what my confusion comes from.On the other hand it couldn't be that these cinema.framework libraries are really statically linked into the plugin DLL's, regarding to the final size of them and it also wouldn't make any sense to include the api itself in the plugin code as it just provide the hooks to the main application (C4D itself) as far as I understand the background of that all. I'm still confused.
By the way, some other questions apart from that:
1. Why are there still predefined configs for Win32 in the project even though they have to be useless since C4D is x64 only up from R15?
Not that it really annoys me, I'm just wondering.2. Why are the release versions of the framework so much bigger than the debug versions?
Around 300 MB (!!!) for the release libs vs. about 12 MB for the debug libs.
I would have expected the release libs to be slightly smaller than the debug versions.Kind regards,
Tom
[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.
-
On 02/10/2014 at 08:12, xxxxxxxx wrote:
If you look in the cinema4dsdk sln, you will find a proper setup example.
the cinema4dsdk project constitutes the plugin body while the cinema.framework project constitutes a dependency (its API).Editing the properties, you will find out that the cinema.framework (the api) is built as a library while the cinema4dsdk (the plugin) is built as a DLL.
The resulting plugin contains its own API and can, therefore, be used on future versions of C4D, provided only addition are made to the API (that's what we do). I believe the libs are not included in the resulting CDL file. they link with cinema 4D instead.
Some more insights are found here - its about R15 and wasn't updated with R16, but it shows the same library/dll configuration.
http://c4dprogramming.wordpress.com/2012/09/30/creating-a-new-plugin-project-in-visual-studio/Let me know if this helps.
Originally posted by xxxxxxxx
Originally posted by xxxxxxxx
Originally posted by xxxxxxxx
Can someone please tell me the differences between the Debug/Release/Intel and the LibDebug/LibRelease/LibIntel configurations in the VisualStudio project for the cinema framework?
The framework is build in the Cinema 4D project build and requires these configurations.
The intel compiler is used to produce the final build of C4D. There is no debug build under Intel.
Which one we use depends of our needs...Yeah, what "Debug", "Release" and "Intel" is for, was clear so far of course. !
Wink[URL-REMOVED]
My question was just related to the "Lib..." part in the configs.
The difference of the respective configs with the "Lib" and without the "Lib" in the name.According to your explanation that would mean the one group is for creating dynamic and the other one for creating static libraries.
Thank you for answering that so far.
Originally posted by xxxxxxxx
Can I ask why you you are asking?
I asked because I was unsure which config to choose for compiling my plugins.
I precompiled all the x64 versions of the c4d api (cinema.framework) for the VS compiler, so that I could link them directly to my plugins without the need to rebuild the framework again and again everytime I compile or recompile some of my own code.
And all produced (I guess) static libraries:
x64_Debug: cinema.framework_Debug_64bit.lib
x64_Release: cinema.framework_Release_64bit.lib
x64_LibDebug: cinema.framework_LibDebug_64bit.lib
x64_LibRelease: cinema.framework_LibRelease_64bit.libSo I was (and in fact still am) unsure which one to use.
I guess it would have to be the "Lib..."-variations for the cinema.framework (x64_LibRelease & x64_LibDebug) and the other ones (x64_Release & x64_LibDebug) for the plugins itself as they have to be dynamic. (I mean, *.cdl and *.cdl64 are in fact simple *.dll's, only renamed)
But it seems like "cinema.framework_Release_64bit.lib" (and "cinema.framework_Debug_64bit.lib") would also work instead. And in fact they would have been even my first choice so far.
That's what my confusion comes from.On the other hand it couldn't be that these cinema.framework libraries are really statically linked into the plugin DLL's, regarding to the final size of them and it also wouldn't make any sense to include the api itself in the plugin code as it just provide the hooks to the main application (C4D itself) as far as I understand the background of that all. I'm still confused.
By the way, some other questions apart from that:
1. Why are there still predefined configs for Win32 in the project even though they have to be useless since C4D is x64 only up from R15?
Not that it really annoys me, I'm just wondering.[/QUOTE]
That`s something we forgot when we removed the Win32 target in R16.Originally posted by xxxxxxxx
2. Why are the release versions of the framework so much bigger than the debug versions?
Around 300 MB (!!!) for the release libs vs. about 12 MB for the debug libs.
I would have expected the release libs to be slightly smaller than the debug versions.I don`t know. definitely looks weird to me.
Originally posted by xxxxxxxx
Kind regards,
Tom
[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.
-
On 02/10/2014 at 08:46, xxxxxxxx wrote:
Originally posted by xxxxxxxx
If you look in the cinema4dsdk sln, you will find a proper setup example.
the cinema4dsdk project constitutes the plugin body while the cinema.framework project constitutes a dependency (its API).Editing the properties, you will find out that the cinema.framework (the api) is built as a library while the cinema4dsdk (the plugin) is built as a DLL.
The resulting plugin contains its own API and can, therefore, be used on future versions of C4D, provided only addition are made to the API (that's what we do).
Some more insights are found here - its about R15 and wasn't updated with R16, but it shows the same library/dll configuration.
http://c4dprogramming.wordpress.com/2012/09/30/creating-a-new-plugin-project-in-visual-studio/Let me know if this helps.
Don't get me wrong, I did several C++ plugins for C4D before from R9.6 up to R15 with the Express Editions of VS 2005, VS 2008, VS 2010 and now VS 2013.
My goal is to completely remove the cinema.framework project from the solution for my plugin and instead use e.g. the precompiled "cinema.framework_Release_64bit.lib" as an additional dependency. How I did it from R10 up to R15 with the "_api_x64_Release.lib" regarding to this example.
But, to bring the core of my problem down to the point:
To compile the cinema4dsdk from R16 as "final", should I choose the "Release" or the "LibRelease" config (the platform is always x64 now of course)?I tried both and both work. They resulting "cinema4dsdk.cdl64" even has the same sice in both cases (722.944 Bytes) but there are 24 differences in the binaries.
110: 8F DE 111: 70 6E 89BF4: 8F DE 89BF5: 70 6E 89C10: 8F DE 89C11: 70 6E 98904: E1 9C 98905: DD D1 98906: 78 3C 98907: AC EF 98908: 07 3D 98909: 1F 47 9890A: 95 D2 9890B: 4D 46 9890C: 96 97 9890D: 9A B6 9890E: B8 FF 9890F: AF AE 98910: 11 E9 98911: 23 F0 98912: AB C8 98913: 22 B1 A5D84: 8A DA A5D85: 70 6EBut don't know what that means in detail and if it would have any impact in practice too?
I would tend toward "Release" not to "LibRelease", but that's just a feeling...
And what's about my other two questions?
Kind regards,
Tom -
On 02/10/2014 at 08:57, xxxxxxxx wrote:
I use "release and x64" personnally. I'll see if I can gain more insight on that.
On the other questions - I modified my message right after sending, the win32 target shouldn't be there. it's a mistake. for the lib size, I don't know and need to look that up.
-
On 02/10/2014 at 12:51, xxxxxxxx wrote:
Originally posted by xxxxxxxx
I use "release and x64" personnally. I'll see if I can gain more insight on that.
On the other questions - I modified my message right after sending, the win32 target shouldn't be there. it's a mistake. for the lib size, I don't know and need to look that up.
Okay, thank you so far.
And I'm looking forward to what you'll find out about the lib size. -
On 07/10/2014 at 08:09, xxxxxxxx wrote:
Phoenix,
I just talked to one of our developers about the framework library size. The development is aware of this, but as this has no influence on the size of plugins linked against the release version of the framework lib, the priority is rather low. It's also not that straight forward, it seems to be correlated to the optimizations the compiler is applying (current thinking goes into the direction of some duplication of code). Please be patient, we are looking into this, and I have noted this on my ToDo list.
-
On 07/10/2014 at 16:04, xxxxxxxx wrote:
Originally posted by xxxxxxxx
I just talked to one of our developers about the framework library size.
Thank you again for talking to the developers and informing us.
Originally posted by xxxxxxxx
The development is aware of this, but as this has no influence on the size of plugins linked against the release version of the framework lib, the priority is rather low.
Yup, that also corresponds with my observations/experiences so far.
Originally posted by xxxxxxxx
It's also not that straight forward, it seems to be correlated to the optimizations the compiler is applying (current thinking goes into the direction of some duplication of code). Please be patient, we are looking into this, and I have noted this on my ToDo list.
Okay, good to know.
Because nevertheless it should be fixed sooner or later, in my opinion. -
On 19/10/2014 at 01:47, xxxxxxxx wrote:
Hi
@joe
to your question on the first page.
I tried to move the sdk and make it ready with xcode 5.1.1, too.
That might be a solution :hhttps://developers.maxon.net/forum/topic/8228/10726_moving-xcode-project-compile-error-xcode-solved
Please let me know if this works for you or if it´s even a acceptable way.
Best wishes
Martin