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
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
