[PD-dev] pd.app & internal paths

[Hans-Christoph Steiner]

On Nov 15, 2005, at 12:55 PM, Frank Barknecht wrote:

> Hallo,
> james tittle hat gesagt: // james tittle wrote:
>
>> ...back to working on the app_pkg stuff, and I have a question:  how
>> are we supposed to access the internally-kept abstractions?
>> Currently, pd++.app/Contents/Resources/extra & pd++.app/Contents/
>> Resources/doc/5.reference seem to be the only places that are in pd's
>> path by default, yet there is also the pd++.app/Contents/Resources/
>> doc/abstractions folder that includes footils/list-abs, among other
>> things:  what is the strategy to access this?
>
> Actually this may be a good time to generally discuss how to deal with
> abstractions. In my opinion there should be a common place for
> abstractions like "extra" is for externals. No messing with the
> Pd-path should be necessary to see these abstractions.
>
> Of course we could simply use "extra" as well. Personally I prefer to
> keep abstractions and externals apart. But I would really like to see
> an "install target" for abstractions as well. I would vote for
> "PD_ROOT/abs/", and maybe also a special help path
> "PD_ROOT/doc/6.abs.reference/" to put the help files for these
> abstractions. (All [list]-abs files contain proper help patches.)

One of the problems is the vague definition of "abstraction" and  
"external".  I think that "application" and "object" are much more  
useful distinctions.

When talking about the distros, I think we should group objects by  
functionality, not how they are implemented.  So objects written in Pd,  
C, C++, Ruby, whatever would all into the same structure.  That's how  
you think about the objects when you are using them within Pd.

As for the CVS structure, it makes sense to me to group objects, etc.  
by how they are implemented so that they can have a common build  
system.  For example, "abstractions" in CVS is a good place to put  
objects written in Pd, then there would be a common Makefile for  
building the abstractions distro. It seems to me that the CVS would  
best be organized around build systems.  So ideally, at the root of the  
CVS, we would have "abstractions" (or whatever) for Pd objects,  
"externals" for C, "flext" for C++/flext, "Gem" for Gem/GemLibs (unless  
it could be integrated into the externals/build system), etc.

.hc


________________________________________________________________________ 
____

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.
Now that he can realize them, he must either change them, or perish.
		                                                -William Carlos  
Williams