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