On Mar 4, 2006, at 8:20 PM, Hans-Christoph Steiner wrote:
On Mar 3, 2006, at 6:56 AM, Tim Blechmann wrote:
On Fri, 2006-03-03 at 10:29 +0100, Thomas Grill wrote:
I'm against managing foreign plugins or apps in the Pd CVS. With an open application like Pd, where an external can be made to load *everything*, there just is no stopping point, once we start to do this.
Hi all, that is also my point of view. There should be no resources in the CVS that can be aquired elsewhere.
right ... if one would want to automate a build process, it can easily be done by adding the command to acquire the resources to the build system ... (doing that with scons seems to be trivial)
There is one major caveat to doing that: it will not work at all with the Debian auto-builders. No network access allowed.
I still see no reason why we should not use CVS to manage "foreign" sources. We already are in a lot of places and it works quite well. We need to use a lot of code that is far from released in building Pd. That means we have to manage source code. CVS is a good tool for managing source code, we all know how to use it, (many of us don't use python or scons at all), and even has built- in support for managing foreign sources. Check out the "Tracking Third-Party Sources" section in the CVS manual:
http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_13.html#SEC106
Really it comes down to this: How are you guys harmed if I choose to manage some "foreign" sources in the Pd CVS?
I forgot to add two things:
first, I really don't see why this is such a contentious issue. I have no interest in pissing anyone off, so please forgive me if it may come across like that. Its just that I have spend far and away the most time working on making Pd into installer packages, and not using CVS for foreign sources would make it A LOT more work to build and maintain Pd and all the externals.
Second, if we were to remove foreign sources, here are some of the things we would have to remove and track separately:
externals/sc4pd/source (SuperCollider is maintained elsewhere) externals/grill (maintained in a separate repository with separate binary releases) externals/hcs/hid/linux/input.h (Linux header, should Mac OS X and Windows users have to track this one?) externals/hcs/hid/HID Utilities Source (Apple sources) externals/gridflow (maintained and released elsewhere) externals/OSCx/libOSC (library from UC Berkeley) externals/iemlib/src/iem_mp3 (uses source files from lame) pd/portaudio (V19 is still very much under development, no releases, big changes) pd/portmidi
Would we be better off if we removed all these? What I am saying we do is what Thomas currently does with his externals/grill directory: import sources which are known to build and work. No one is saying we should include GTK or something like that. But for things that are under development and/or have no releases, CVS is a good tool to manage those sources. This is standard practice, and indeed, CVS is designed to do this.
Plus with changing sources, we can import sources that we know work with Pd instead of having the whole Pd build system break whenever some developer on portaudio, libOSC, etc. etc. makes a change. This will make bugs much easier to track since we'll know which version of a given library (like portaudio) works well with Pd.
.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.