[GEM-dev] import stable snapshots to pure-data CVS

[Hans-Christoph Steiner]

On Apr 20, 2005, at 5:38 AM, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> On Apr 19, 2005, at 5:04 PM, james tittle wrote:
>>> On Apr 19, 2005, at 4:04 PM, Hans-Christoph Steiner wrote:
>>>
>>>>
>>>> Currently there is no gem in the pure-data CVS AFAIK.  I think that  
>>>>  "externals/gem" would be a good location for all of the gem  
>>>> related  files.  So it would be like:
>>>>
>>>> externals/gem/Gem
>>>> externals/gem/GemLibs
>>>> externals/gem/whatever else is needed
>>>
>>>
>
>> I think we should put everything that is needed to build Gem in   
>> externals/gem.  On another project that I work on, ewrt, this is how   
>> its done.  They are using sources from all over the place, so they   
>> import whatever version they deem stable.  Then you can make branches  
>>  to take changes to these imported sources so that those changes can  
>> be  submitted to the upstream developers.
>
> hmm, this is really tough: on my machine (running debian) all (i  
> repeat: ALL) dependencies for gem are handled by debian itself (at  
> least all "hard" dependencies; there might be one or two "soft"  
> dependencies that are only in marillat's non-free section (but i don't  
> think so))
>
> while i normally use sarge/sid, i am pretty sure that woody fullfills  
> all hard dependencies.
>
> just recently i managed to compile Gem on slackware, and it turned out  
> that only very few things were missing (i have no experience with  
> slackware, but i think it is one of the distros with the least  
> multimedia-packages)
>
> ....
>
> so to conclude (note that i am speaking mainly about linux)
> Gem has several "hard" dependencies (like openGL, X, and some image  
> loading libraries): we cannot include these into the source  
> distribution for obvious reasons.
> Gem has several "soft" dependencies (all the video-loading stuff; the  
> font-rendering stuff): these are soft on purpose! as jamie has pointed  
> out, for getting font support you need ftgl which depends on freetype2  
> OR gltt which depends on freetype1; i have no idea what dependencies  
> are there for libavifile, as i have never tried to compile it myself.
>
> as with os-X, Gem depends heavily on quicktime (as jamie has pointed  
> out), we cannot provide that!
>
>
> so in general, i don't think that we should provide sources for  
> packages that are widely available otherwise (e.g. on sourceforge!)
>
> GemLibs is more or less empty !
> it's just that no one bothered to remove things from there; all the  
> "weird libraries" that no one would find and/or that had to be  
> modified to work with Gem are already included into the core of Gem.
>
> the real task would be to write good (and up to date) COMPILATION.txt  
> files that describe the required packages.
>
> to conclude again: providing an environment that allows to build pd  
> (+Gem/pdp/pidip) should definitely _not_ result in a new  
> lin/win/osx-distribution.
>
>
>> As for source vs. binaries, I would put the stuff up there as source,  
>>  until its something that is quite hard to compile and has a lot of   
>> non-standard dependencies.
>
> i totally agree
>
>
> mfg.asd.r
> IOhannes


You are taking "include everything" much too literally.  If we took  
that to its logical conclusion, gcc, the linux kernel, glibc, etc would  
need to be included.  Everything that Gem need in order to compile on a  
standard dev configuration of a given OS should be included.  On  
Debian, you don't need much at all since it can all get apt-get'ed.  On  
MacOS X, you might need a couple things.  On Windows, I imagine you  
need quite a bit of stuff.

I am going on my last experience trying to build Gem from CVS in the  
winter.  The makefiles were looking for the sources of a few libs, I  
think freetype was one, but they weren't in CVS.  This was on Mac OS X.

In terms of bug tracking, it might be a good idea to build against the  
same version of all libs on all OS's.  So if Windows needs the source  
to freetype, then Linux and MacOS X builds should use that same source.  
  That would insure that all platforms are using the exact same lib  
version.  Again, just an idea.  Ideally, Pd releases would be as close  
to exactly the same on all platforms.  This would help with running  
patches cross-platform and also help with debugging.

.hc


________________________________________________________________________ 
____

Using ReBirth is like trying to play an 808 with a long stick.
								-David Zicarelli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2353 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20050420/1ae04ad9/attachment.bin>