So I was thinking that it would be very handy to have stable snapshots of Gem in the pure-data CVS so that Gem can easily be compiled and included in the build system. The idea would be that whenever Gem has a stable release, we'll import the sources into the pure-data CVS.
This will also be helpful with compiling gem2pdp and pgp2gem since we can set the build to use the Gem source from the pure-data CVS, where pdp2gem are already.
I'll restrict access to the gem-devs and me (so I can do the importing). Then people can make branches if they want to work on Gem in the pure-data CVS.
Any objections, comments, etc?
.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
On Apr 18, 2005, at 5:35 PM, Hans-Christoph Steiner wrote:
So I was thinking that it would be very handy to have stable snapshots of Gem in the pure-data CVS so that Gem can easily be compiled and included in the build system. The idea would be that whenever Gem has a stable release, we'll import the sources into the pure-data CVS.
This will also be helpful with compiling gem2pdp and pgp2gem since we can set the build to use the Gem source from the pure-data CVS, where pdp2gem are already.
I'll restrict access to the gem-devs and me (so I can do the importing). Then people can make branches if they want to work on Gem in the pure-data CVS.
Any objections, comments, etc?
...I think this is a "why aren't we doing it already" kinda issue :-) The answer is that no-one has stepped forward and actually done it...I'm guessing that it isn't up to date with 0.90.1 atm?
l8r, jamie
james tittle wrote:
On Apr 18, 2005, at 5:35 PM, Hans-Christoph Steiner wrote:
...I think this is a "why aren't we doing it already" kinda issue :-) The answer is that no-one has stepped forward and actually done it...I'm
the answer is simple: when i proposed it to hans at the pdcon04, he told me that this was non-sense: if the code development wasn't done at the pd-cvs, why should the code be there (or something alike this)
i still think that it is a good idea i still want to do the gem development on pd-gem instead of pure-data.
guessing that it isn't up to date with 0.90.1 atm?
i don't think so.
mfg.asa.ui IOhannes
On Apr 19, 2005, at 2:42 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
On Apr 18, 2005, at 5:35 PM, Hans-Christoph Steiner wrote:
...I think this is a "why aren't we doing it already" kinda issue :-) The answer is that no-one has stepped forward and actually done it...I'm
the answer is simple: when i proposed it to hans at the pdcon04, he told me that this was non-sense: if the code development wasn't done at the pd-cvs, why should the code be there (or something alike this)
i still think that it is a good idea i still want to do the gem development on pd-gem instead of pure-data.
Since gem is going to remain in a separate CVS, this is a good workaround. I was trying to get all of the Pd source code into one repository so we can have complete dev builds automatically generated, tagged versioning across all the code, etc., etc. But its now obvious that the gem devs don't want this.
guessing that it isn't up to date with 0.90.1 atm?
i don't think so.
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
Then all of the gem stuff would be in one folder rather than scattered around the already crowded "externals".
.hc
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
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
...this is what confuses me: are we supposed to put freetype 2 and ftgl up in source form, or binaries? Similar situation with pdp (dependent on gsl, libjpeg, libquicktime, etc but some are optional), and I wouldn't even hazard a guess at how you'll get yves to assemble and maintain the dependencies for pidip! And how are "optional" libraries dealt with? Fr'instance in Gem on osx, we just use quicktime; on linux, there's many possible methods for images/films...
l8r, jamie
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
...this is what confuses me: are we supposed to put freetype 2 and ftgl up in source form, or binaries? Similar situation with pdp (dependent on gsl, libjpeg, libquicktime, etc but some are optional), and I wouldn't even hazard a guess at how you'll get yves to assemble and maintain the dependencies for pidip! And how are "optional" libraries dealt with? Fr'instance in Gem on osx, we just use quicktime; on linux, there's many possible methods for images/films...
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.
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.
.hc
________________________________________________________________________ ____
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
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
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
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
james tittle