[PD-dev] including [dssi~] in Pd-extended

[Hans-Christoph Steiner]

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.