[PD-dev] PureUnity now includes an "external"

[Hans-Christoph Steiner]

On Jan 7, 2006, at 12:54 PM, Mathieu Bouchard wrote:

> On Sat, 7 Jan 2006, Hans-Christoph Steiner wrote:
>>
>> Because when you mix up files of different types, it makes the pattern
>> matching rules more complicated.  I am sure there are other reasons as
>> well, that's the first that comes to mind.
>
> Does it? wow. Then how come there are so many *.pd files in the
> /externals/ module ?

I mean more having all of the files in one directory, not which tree  
its in.  But if a lib needs something compiled, it should go into  
/externals/. That way we don't need to add any compilation stuff to  
/abstractions/Makefile, which would just be a duplicate of  
/externals/Makefile

Perhaps a better distinction than /abstractions/ and /externals/ would  
be /applications/ and /objects/.  /applications/ would always be only  
.pd files since this is the repository for Pd.  /objects/ could be any  
kind of code, since Pd objects can be written in many languages.

> Also, I'm curious about how you would break down pureunity into  
> individual
> externals.

I'd probably have something like:

pureunity/src (*.c)
pureunity/abs (*.pd)
pureunity/help (*-help.pd)

> Several "classnames" defined in it are aliases
> (class_addcreator) but not aliases of classes defined in PureUnity!
> they're aliases for internal classes, e.g.:
>
> [f.inlet] is same as [inlet]
> [~.inlet] is same as [inlet~]
>
> Would each call to class_addcreator have to go in a separate C file?

You could use symlinks, except on Win32, where you would need copies  
(Win32 doesn't have real symlinks, except with Cygwin.).

.hc
________________________________________________________________________ 
____

If you are not part of the solution, you are part of the problem.
                                                                          
                            - Eldridge Cleaver