Build on Windows

[charlesangus]

Plugins have only been built/tested on Centos Linux.

[jonassorgenfrei]

Hey @charlesangus,
i would like to help out with the Windows Site for DeepC.
I will take a look and create a PR when i got it working.

[charlesangus]

Awesome, thanks! Looking forward to it.

[charlesangus]

I can't remember all the issues I've run into trying to get this to work, and it's been a while since I've tried, so sorry for the vagueness:

• there's a variable, I think one of the enums, that shadows some built-in variable on Windows and needs to be changed (easy enough to fix)
• I seem to recall there's something in the way the classes are structured or something that's not supported on Windows, which is a bit of a sticky wicket

Stay in touch and post any error messages you get stuck on and I'll see if I can remember anything more.

[jonassorgenfrei]

Don't worry i will just find my way trough the compiler errors :) and adjust them accordingly.

I see thanks for the heads up :)
Yeah saw some array initializiation too which doesnt compile on windows like
float myArray[amount]

Will go trough it this weekend to make it code wise working and in the beginning of next week i will get a nuke dev licence to test it out in nuke then :)

[jonassorgenfrei]

Got it working (the compiling step). Will test next week when i am able to run it in nuke :)

[jonassorgenfrei]

Okay finally got my nuke licence and was able to test it.
It compiles and loads in nuke but i get access violations when running any DeepCWrapper at
DeepCWrapper.cpp line 356
return dynamic_cast<Iop*>(op)

@charlesangus can you tell me what the test_input function is supposed to do?

[jonassorgenfrei]

Okay seems like it is something with my settings. The examples crash too. Will investigate more into it.

EDIT: Got the examples working now; will try to use them as reference to find out whats going wrong. Have a little bit the feeling the compiler/nuke doesn't like the wrapper module 🤔

[charlesangus]

The test_input function, iirc, is what determines whether the input pipe can be attached to a given node.

…

On Thu., Dec. 2, 2021, 21:17 Jonas Sorgenfrei, ***@***.***> wrote: Okay seems like it is something with my settings. The examples crash too. Will investigate more into it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABD5T4KOKEXOAJJLQD32BP3UPASDHANCNFSM4GJNJ4JQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[jonassorgenfrei]

Works on windows now:
https://github.com/jonassorgenfrei/DeepC

Could anyone with a linux machine give it a try to make sure i didn;t break anything there?
@charlesangus @falkhofmann

The main problem was line 360ff:
default_input(int input)
With the missing initializer for the dummy cast:
Black* dummy = new Black(); return dynamic_cast<Op*>(dummy);

Is there any reason why the Black Dummy cast was used instead of a return 0?
Since currently when using dynamic_cast<Op*>(dummy);
The node defaults on site_maks rgba.alpha and i need to disable it for seeing any result.
When using return 0 on the second input it works fine as expected.

[falkhofmann]

hey jonas,
i gave your fork a spin, build and loaded them.
seems to work fine. at least i dont see an issue inside nuke.

nevertheless I do agree on the side mask default. would better to have it turned of on default/creation.

but when i am building from my fork the defaults are correct.
so this might be something to take care of.