Skip to content
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

Closed
wants to merge 47 commits into from
Closed

Nuke node #42

wants to merge 47 commits into from

Conversation

JGoldstone
Copy link

Includes UI and Nuke fixes from Jonathan Egstad and a Nuke fix from Kimball Thurston 3rd.

JGoldstone and others added 30 commits October 14, 2013 21:21
…ameFromPathname when looking for top-level module.
- 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).
…ion calls are not thread-safe; remove pre-rewrite code fragments.
…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.
@aforsythe aforsythe mentioned this pull request May 28, 2014
@up4
Copy link

up4 commented May 28, 2014

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.

@JGoldstone
Copy link
Author

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" <notifications@github.commailto:notifications@github.com> 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.


Reply to this email directly or view it on GitHubhttps://github.com//pull/42#issuecomment-44454958.

@up4
Copy link

up4 commented May 28, 2014

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

@aforsythe
Copy link
Member

Joseph,
Can you also rebase the current ampas/master branch onto your NukeNode branch. From what I can tell the merge should be a fast forward, but for some reason I'm getting a bunch of conflicts. I think it'd be best for you to reconcile them since you're the author of the NukeNode.

Thanks
Alex

@up4
Copy link

up4 commented May 29, 2014

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…

@JGoldstone
Copy link
Author

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" <notifications@github.commailto:notifications@github.com> 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…


Reply to this email directly or view it on GitHubhttps://github.com//pull/42#issuecomment-44585433.

@JGoldstone
Copy link
Author

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—
—joseph

On May 29, 2014, at 5:32 PM, Joseph Goldstone <jgoldstone@arri.commailto:jgoldstone@arri.com> 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" <notifications@github.commailto:notifications@github.com> 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…


Reply to this email directly or view it on GitHubhttps://github.com//pull/42#issuecomment-44585433.

Enc:

@up4
Copy link

up4 commented May 30, 2014

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!

@JGoldstone
Copy link
Author

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—
—joseph

On May 28, 2014, at 5:45 PM, Alexander Forsythe <notifications@github.commailto:notifications@github.com> wrote:

Joseph,
Can you also rebase the current ampas/master branch onto your NukeNode branch. From what I can tell the merge should be a fast forward, but for some reason I'm getting a bunch of conflicts. I think it'd be best for you to reconcile them since you're the author of the NukeNode.

Thanks
Alex


Reply to this email directly or view it on GitHubhttps://github.com//pull/42#issuecomment-44468748.

@hpd
Copy link

hpd commented Jun 11, 2014

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!
HP

@JGoldstone
Copy link
Author

I hope to have a merge (with Alex’s help) upstream by day’s end.

On Jun 11, 2014, at 9:40 AM, hpd <notifications@github.commailto:notifications@github.com> 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!
HP


Reply to this email directly or view it on GitHubhttps://github.com//pull/42#issuecomment-45766985.

@up4
Copy link

up4 commented Jun 20, 2014

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:

screen shot 2014-06-20 at 4 46 59 pm

I would like this to work before trying the CTL plugin to make sure the problem is not simply in my dev environment…

Thanks!

@up4
Copy link

up4 commented Jun 20, 2014

I'm sorry. It works! I will try to compile (maybe outside Xcode first) tomorrow.

@scottdyer
Copy link
Contributor

Superseded by #51. Closing.

@scottdyer scottdyer closed this Jul 22, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants