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

[Hans-Christoph Steiner]

On Oct 22, 2011, at 11:07 AM, IOhannes m zmoelnig wrote:

>>> I am waiting on definitive answers on two questions, until then, I'm
>>> sticking to the  current setup.
>>>
>>> - are you dropping support for the Gem SVN?
>
> i don't understand that question.
> what does "support for the SVN" mean?
>
> i announced a switch to git, which means that any future development  
> (and bug
> fixes) will be done in git. no future development is planned in svn.
>
> as long as the svn is available and i find time, i'd like to sync at  
> least
> release branches.
> it is not likely that "quick fixes" will make it (quickly) into svn.

Thanks for answering my questions.

Like I said before, this will unfortunately greatly limit the work  
that I can do on Gem.  I have much less time to spend on Pd dev work  
these days due to having and supporting a family.  Currently I work on  
gem as part of the Pd-extended releases.  I mostly do lots of little  
fixes like getting the paths to example media right in the help files,  
and other things like that.  Things that mostly newbies and students  
notice, since teaching intros is the only thing I do with Gem.  That's  
all integrated in the pure-data SVN nicely.

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.

http://sourceforge.net/tracker/?func=detail&aid=3414731&group_id=64325&atid=507081

We definitely need to get more people involved in Gem dev, I hope that  
the git will make that easier. My two bits is that this move to git  
felt to me like a decision made by you, IOhannes, without input from  
other committers.  Yes, you do the vast majority of the work on Gem  
these days, but I think it would have been good to include other  
committers in the discussion.

>>>
>>> - are you dropping support for building on Mac OS X 10.5 without  
>>> Fink?
>
> no, why do you think so?
> when doing my builds, i usually do not have fink installed at all.
> this also means that my tests are usually done without fink. any  
> problems
> arising from fink are therefore less likely to get caught.
>
> nevertheless i'm happy to point to quick fixes for given problems  
> (like adding
> /sw/bin to the beginning of PATH before running Gem's autogen.sh)

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 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.


>> 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'.   
Then for Mac OS X and Windows, use the builds posted on gem.iem.at.   
That's is already the case for Windows and has been for a while.  For  
the 0.43 Pd-extended release, I think I'll do one last cycle of  
importing the release source into Pd-extended release branch and  
working from there.

.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