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

[IOhannes m zmoelnig]

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