On Oct 23, 2011, at 12:01 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/22/2011 09:20 PM, Hans-Christoph Steiner wrote:
As for the gem git process, I don't really know what it is. I assume its like pure-data.git, so I submitted a patch, and updated it based on your feedback, and its still open with no comment almost a month later.
thanks for submitting a patch.
in case you are interested, i have a number of patches in the puredata patch-tracker which have not been answered by miller.
I'm just trying to get some clarity on what your new process is with Gem, now that its in git.
The current setup with the fink paths last has been there a long time, and everything worked fine with it in the past, including Gem. The key
and then something changed: you upgraded the build host to 10.5 and it stopped working. i'm not saying that you are to blame, and indeed the autogen.sh file _is_ buggy; i'm only suggesting how you could generate a build without having to switch to git (which it seems you don't want to do, as it doesn't integrate nicely into the current svn setup)
I prefer git over svn, sure. I just don't have much time to spend on Pd these days, so I need to prioritize, and switching to managing Gem from git isn't something I have time for. The Pd-extended build setup is old and kludgey, so it is not so flexible. If anyone else want to take that on, I'm open to it. And I'm trying to nail down the core Pd 0.43 bugs before I have to disappear for a bit.
idea there, IIRC, is that it provides a way to make sure that builds work with the internal tools, and only get things from Fink that Mac OS X does not provide. I believe this was done to help test things like Gem's support for plain Mac OS X, but I could be wrong.
i cannot remember anything about the whys and hows, so i cannot help here. however, your statement makes me a bit confused, as i thought that the pd-extended autobuild process is _not_ about testing things, but rather about getting consistent pd-extended builds.
First and foremost, it is about getting consistent Pd-extended builds. But it also clearly serves as a testing platform as well. But that comes second.
Oops, one more question:
- are you planning on making Mac OS X builds?
yes; sorry that this takes so long.
I'm thinking that for Gem in Pd-extended, I'll use the Gem binaries then. For Debian/Ubuntu, I'll just make the package depend on 'gem'.
btw, my osx binaries will not be build against gmerlin,... and the like, only OSX internals (QuickTime or whatever); FTGL will be statically linked.
I can't see any problem with that. I think the only difference between the versions included in Pd-extended is that FTGL is dynamically linked.
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin