Well, that was just a hack to make sure the Carbon framework wasn't being pulled in. I realize now I could just do ./configure --without-quicktime. That was one of the aforementioned hacks I wanted to clean up before pushing. I pushed when you requested and now I get a note about the very thing I didn't want to push :P Trust me, it won't be like that in the final commit.
On Feb 26, 2014, at 6:00 AM, gem-dev-request@iem.at wrote:
btw, is it intentional that you have disabled quicktime4linux support in your updated configure.ac? i would highly appreciate to put code that potentially effects "others" (e.g. the linux port) into separate commits. this includes all files outside "plugins/*AVFoundation/" (namely configure.ac, Makefile.am,...)
-------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-02-26 15:27, Dan Wilcox wrote:
Well, that was just a hack to make sure the Carbon framework wasn't being pulled in. I realize now I could just do ./configure --without-quicktime. That was one of the aforementioned hacks I wanted to clean up before pushing. I pushed when you requested and now I get a note about the very thing I didn't want to push :P Trust me, it won't be like that in the final commit.
no problem. i did not want to sound grumpy, esp. since i'm really thankful that you do that!
but then, i just wanted to express what i think is good practice for committing before it's *way* too late.
fgmasdr IOhannes
I can stage commits between source areas. That first one was a quick push before going out the door.
Also, is there some reason why [gemwin] wouldn't create? I'm building for 64 bit and testing using Miller's Pd-0.45-4-64bit app. All other GEM objects seem to create fine except for gemwin. I have a few window-api specific objects in the main GEM build dir ([gemmacwindow], [gemsdlwindow], [gemcocoawindow], [gemglutwindow]) but none of them seem to give me a complete rendering context aka a window but no GL.
On Feb 26, 2014, at 9:30 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-02-26 15:27, Dan Wilcox wrote:
Well, that was just a hack to make sure the Carbon framework wasn't being pulled in. I realize now I could just do ./configure --without-quicktime. That was one of the aforementioned hacks I wanted to clean up before pushing. I pushed when you requested and now I get a note about the very thing I didn't want to push :P Trust me, it won't be like that in the final commit.
no problem. i did not want to sound grumpy, esp. since i'm really thankful that you do that!
but then, i just wanted to express what i think is good practice for committing before it's *way* too late.
-------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-02-26 15:36, Dan Wilcox wrote:
I can stage commits between source areas. That first one was a quick push before going out the door.
great.
Also, is there some reason why [gemwin] wouldn't create? I'm building for 64 bit and testing using Miller's Pd-0.45-4-64bit app. All other GEM objects seem to create fine except for gemwin. I have a few window-api specific objects in the main GEM build dir ([gemmacwindow], [gemsdlwindow], [gemcocoawindow], [gemglutwindow]) but none of them seem to give me a complete rendering context aka a window but no GL.
add "./abstractions" to your path. [gemwin] is moving to an abstraction-implementation with the various window-api specific objects as backends; they should create a complete rendering context just fine, but won't do any setting up in openGL-land (which is all done by the abstraction).
fgmasdr IOhannes