It’s been awhile since I’ve done any development on NUKE, so when the other day I was asked to put together a simple plugin on OSX, I thought it would be a good time to try and create a simple XCode project to do my development in.
My reasoning for doing this was two fold. Firstly, Nuke’s SDK currently ships with a simple Makefile that you can use to build all of the example plugins. However, it uses GCC as the compiler and references the 10.6 SDK (!), both of which hasn’t shipped with XCode for an age. The second reason is that XCode nowadays provides lots of really useful features, so while I don’t mind programming in Terminal and VIM, it’s much more enjoyable to take advantage of all the modern features available.
For those who don’t want to create it from scratch, I’ve put the finished XCode project up on github, feel free to clone and modify to your hearts content! The “ExamplePlugin” does a very simple greyscale filter on the RGB channels and maintains the alpha. It’s not all that efficient, but is a simple plugin.
For those who want to do it from scratch, here’s a list of common gotchas that you want to watch out for.
Create a “Bundle Project”
When creating the project, make sure you select “Bundle” under “Framework & Library” rather than something like “Generic C++ Plugin”. This subtly changes the way your code is linked and, if you don’t do this, Nuke won’t be able to load your plugin correctly.
Change the Build Settings
There are various build settings you’ll need to change to get it to compile correctly and then not crash! Here’s the one’s you should change:
- CLANG_CXX_LIBRARY=libstdc++ – By default it’s “libc++”, but as NUKE is compiled with libstdc++, you’ll need to match this, otherwise you’ll get some strange compiler errors about std symbols
- VALID_ARCHS=x86_64 – Pretty obvious, NUKE is 64-bit only
- OTHER_LDFLAGS=-lGLEW -lDDImage – You’ll need to link against DDImage and GLEW to compile your app
- HEADER_SEARCH_PATHS=/Application/Nuke/Nuke.app/Contents/MacOS – Setup your header search paths to whatever version of Nuke you’re targetting
- LIBRARY_SEARCH_PATHS=/Application/Nuke/Nuke.app/Contents/MacOS – Again, set the linker path up to find the DDImage libarary
- MACOSX_DEPLOYMENT_TARGET=10.6 – As NUKE still supports 10.6, you should make sure you build your plugin with 10.6 support. Changing the deployment target means you can still use whatever SDK you have installed, but that it doesn’t allow you to use more modern SDK calls, which is useful.
Add a User-defined setting for the Nuke Application folder
This isn’t necessarily required, but it’ll make changing between versions on NUKE a lot easier. Adding the NUKE_APPLICATION_FOLDER user setting means that in the previous settings, you can put $NUKE_APPLICATION_FOLDER instead of a hard-coded path, and then you just need to change one place in order to get it to compile against a different version! You could even add multiple targets for different versions, which is cool
Add a Post-Build step
Again this isn’t necessarily needed, but it’ll make developing and testing a LOT easier. What I did was simply copy the bundle executable XCode creates and copied it into my “.nuke” folder, which would get picked up by Nuke on startup. Something like this:
cp $CONFIGURATION_BUILD_DIR/$PRODUCT_NAME.bundle/Contents/MacOS/$PRODUCT_NAME ~/.nuke/$PRODUCT_NAME.dylib
For Nuke 9 and above, by default Nuke starts with breakpad enabled, which is a mechanism with which to report crashes back to The Foundry (which is really useful by the way!). In order to allow you to debug your plugin, you need to run Nuke with the following arguments:
/Applications/Nuke<version>/Nuke<version>.app/Contents/MacOS/Nuke <version>--crashhandling 0
This will disable crash handling and allow you to attach XCode to debug your plugin.