[GEM-dev] getting latest Gem into Pd-extended

[Hans-Christoph Steiner]

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