-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nuke node #42
Nuke node #42
Conversation
…mer home in a local repository.
…ting code was taken.
…athname splitters.
…est access in Xcode.
…ameFromPathname when looking for top-level module.
…than anything else.
…ing inside try block.
- removes nuke_ctl in preparation for CTL 1.5 release. nuke_ctl will be released in a future version CTL.
… the better to match Nuke's calling patterns.
…nsform so we can call non-static methods on it.
…ding arg map — it’s hardwired (for now).
…tion of NukeCtlTransform.
…ion calls are not thread-safe; remove pre-rewrite code fragments.
…g the ‘register’ keyword.
…ut deprecated ‘register’ keyword.
…e; member variable name cleanup; add clang pragmas to silence warnings about deprecated ‘register’ keyword.
…er than to the data pointed at by those pointers.
…Transform object.
…put copy member functions.
There are Xcode project files in there. I would like to use those. However, they seem to depend on specific Homebrew formulæ: the NukeCtlLib subproject depends on external libraries (dylib and header files) directly in the Cellar and they are not the versions I'm getting from a standard "brew install" (plus some in the Nuke app package: 8.0v1 in this case). Would it be possible to get those (or where they are located)? I would be testing on Mac OS X 10.9.3 and NukeX 8.0v4. Or would it be better that I just (artistically) relink everything to the versions that I have installed? Thanks. |
I will try and pull this together later tonight. There are some tricky bits because of string arguments in the API, because of Nuke being linked against the libstdc++ library instead of libc++, and because Clang in Mavericks defaults to libc++. But I am at an all-day conference at MIT today and will busy until about 9PM EDT. If I am too tired today I will hit this tomorrow. On May 28, 2014, at 15:43, "Vincent Olivier" <[email protected]mailto:[email protected]> wrote: There are Xcode project files in there. I would like to use those. However, they seem to depend on specific Homebrew formulæ: the NukeCtlLib subproject depends on external libraries (dylib and header files) directly in the Cellar and they are not the versions I'm getting from a standard "brew install" (plus some in the Nuke app package: 8.0v1 in this case). Would it be possible to get those (or where they are located)? I would be testing on Mac OS X 10.9.3 and NukeX 8.0v4. Or would it be better that I just (artistically) relink everything to the versions that I have installed? Thanks. — |
Hi Joseph, Please don't rush yourself to death on this! Take your time. I'd rather have you look at it tomorrow and let you spend some quality time with your code and then I can retry on Friday or even Monday. Just let me know. Take care, Vincent |
Joseph, Thanks |
Oh and, in the meantime, I've been reading about the NDK and it says that building under OS X 10.6 is recommended. Getting gcc 4.0 with libstdc++ on 10.9 (Mavericks) seems impossible (I think I tried pretty much everything)… unless you know how to do it and can tell me. Maybe I will take an old mac to make a 10.6 build machine beginning of next week… |
I'm a bit more awake today. You don't really need either 10.6 or GCC, you just need modified brew formulae for OpenEXR et al. I will try and get those to you tonight as soon as I verify they work after the latest 'brew update'. On May 29, 2014, at 17:09, "Vincent Olivier" <[email protected]mailto:[email protected]> wrote: Oh and, in the meantime, I've been reading about the NDK and it says that building under OS X 10.6 is recommended. Getting gcc 4.0 with libstdc++ on 10.9 (Mavericks) seems impossible (I think I tried pretty much everything)… unless you know how to do it and can tell me. Maybe I will take an old mac to make a 10.6 build machine beginning of next week… — |
Hello Vincent— Enclosed are modified brew formulae for aces_container, ctl, ilmbase and openexr. Do a ‘brew update’, then substitute these for the ones in /usr/local/Library/Formula. That should work for the Nuke CTL plugin (I have tested it with a trivial variant on identity.ctl, but haven’t verified with, say, a non-null CTL_MODULE_PATH). I am a little apprehensive, however, about how this will do with ctlrender and its ability to write TIFF files. Let me explain. The mangled names for std::string changed with C++11. Clang by default generates new-style names, but Nuke is built to expect old-style names. The included formulae force the compilations of aces_container, ctl, ilmbase and openexr to generate old-style names. But parts of the other parts of the CTL distribution, like ctlrender, link with additional third-party libraries for TIFF and JPEG support. The brew system tries to optimize the build times of systems that depend on really common libraries like TIFF by storing pre-brewed (‘bottled’) versions of these libraries, when it’s much faster to download and ‘pour from the bottle’ than it is to download and recompile. But I think the versions that are ‘bottled’ were compiled with the platform-native compiler in its default configuration…which means that libraries like the bottle TIFF library probably use the new-style mangled names for std::string. Therefore I’m not sure how well, if you made additional Xcode targets for things like ctlrender, one would do if one tried to use ctlrender to convert OpenEXR to TIFF, however. This page on the brew website recommends, basically, that one throw in the towel on clang, install GCC 4.8, and reinstall your entire dependency tree. I’d rather figure out how to force brew to abandon the use of bottled TIFF and JPEG libraries. Anyway you should not need to resolve this rather deep problem straight off, but I wanted to mention it here (for others to consider as well) for the future. Let me know how the fork works for you. Best— On May 29, 2014, at 5:32 PM, Joseph Goldstone <[email protected]mailto:[email protected]> wrote: I'm a bit more awake today. You don't really need either 10.6 or GCC, you just need modified brew formulae for OpenEXR et al. I will try and get those to you tonight as soon as I verify they work after the latest 'brew update'. On May 29, 2014, at 17:09, "Vincent Olivier" <[email protected]mailto:[email protected]> wrote: Oh and, in the meantime, I've been reading about the NDK and it says that building under OS X 10.6 is recommended. Getting gcc 4.0 with libstdc++ on 10.9 (Mavericks) seems impossible (I think I tried pretty much everything)… unless you know how to do it and can tell me. Maybe I will take an old mac to make a 10.6 build machine beginning of next week… — Enc: |
Hi Joseph. Thanks so much. I will be able to look at it on Monday and get back to you then. Have a nice weekend! |
Hello Alex— Since the first ampas/master commit past the point where NukeNode branches off starts by immediately deleting a key Nuke CTL node file (NukeCtl.cpp), it seems dubious to rebase the ampas/master branch on top of NukeNode. How would you think I should proceed? Copy the directory tree (except the .git hidden directory) somewhere else, restore the master branch, make a new branch, copy my files back (which will in some cases be additions, even if they were there before master removed them), test, commit, merge, test, push changes to origin? Best— On May 28, 2014, at 5:45 PM, Alexander Forsythe <[email protected]mailto:[email protected]> wrote: Joseph, Thanks — |
…keInputParameters.* and NukeTransform.*.
Hello Joseph, Can you point me to the modified homebrew formulae for aces_container, ctl, ilmbase and openexr? I'm attempting to build the Nuke plugin against 8.0v4 as well. Thanks! |
I hope to have a merge (with Alex’s help) upstream by day’s end. On Jun 11, 2014, at 9:40 AM, hpd <[email protected]mailto:[email protected]> wrote: Hello Joseph, Can you point me to the modified homebrew formulae for aces_container, ctl, ilmbase and openexr? I'm attempting to build the Nuke plugin against 8.0v4 as well. Thanks! � |
… NukeInputParameters.{h,cpp}.
…rom brew, don't use it.
I'm not sure where you guys are with the merge and all. Is this still the latest version? I'm sorry for taking so long. Anyways, I tried to setup my NDK dev environment. I'm testing with the ffmpegReader example provided with NDK 8.0v1. After a few modifications in the Makefile, it compiles. But when I'm trying to load it with the "x" command, I get: I would like this to work before trying the CTL plugin to make sure the problem is not simply in my dev environment… Thanks! |
I'm sorry. It works! I will try to compile (maybe outside Xcode first) tomorrow. |
…txt (updating the latter for current Nuke plugin default search paths).
…someone else can fix this.
Superseded by #51. Closing. |
Includes UI and Nuke fixes from Jonathan Egstad and a Nuke fix from Kimball Thurston 3rd.