[PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)

Hans-Christoph Steiner hans at eds.org
Fri Sep 14 06:14:23 CEST 2007


On Sep 13, 2007, at 1:40 PM, Roman Haefeli wrote:

> On Thu, 2007-09-13 at 11:14 -0400, Hans-Christoph Steiner wrote:
>
>>
>> Again, this is up to the person building them.  For example, the
>> externals that come with Pd in the "extra" folder are built in both
>> ways.  bonk~, fiddle~ are built as single files.  The exprs are all
>> built into one file.  Some libraries (ggee, unauthorized) have been
>> built as single-class-single-file single well before Pd-extended.
>>
>>> iemlib is a special case, because there is not only the
>>> inconsistency of
>>> having namespaces in pd-extended and not having them in
>>> 'pd-vanilla/externals', but also different names of libraries. in
>>> order
>>> to create a patch, that works on both, it's required to have a
>>> [declare]
>>> with the all these flags:
>>> -stdpath iemabs
>>> -stdpath iemlib
>>> -stdlib iemlib1
>>> -stdlib iemlib2
>>> -stdlib iem_t3_lib
>>> just to get iemlib working everywhere.
>>>
>>> since [declare] doesn't output an error, when not finding a lib or a
>>> path, this can be handled this way, though it is a bit awkward.
>>>
>>> yo, lets make it simple: shouldn't the one or the other be  
>>> skipped in
>>> cvs? since the libdir is more widely used, i assume, and has also  
>>> some
>>> advantages compared to the old standard (am i right here?), let's  
>>> skip
>>> the old way of creating externals. i thirst for consistency,  
>>> really. i
>>> am going to found the church of consistency.
>>
>> Sounds like the iemlibs should be should be split up in Pd-extended,
>> then it would be consistent.  Any volunteers?
>
> this not what i was proposing. i was rather referring to this:
>
>>
>> Again, this is up to the person building them.
>
> why? what is the benefit of it, when your decision creates
> inconistencies? since everything seems to be hostet in cvs, why  
> does cvs
> still support two ways of compiling them? i'd like to know from the
> devs, if there is any good reason to keep the old makefiles/readmes  
> and
> stuff in cvs.
> if people finally would find only one makefile/readme: byebye
> inconistencies. it automatically wouldn't make a difference anymore,
> whether you are an pd-extended user or not.

I am totally with you in spirit, but the issues are social, not  
technical.  I think that we should purge all old build systems  
(they'd still be archived in CVS) and replace them all with a  
standard build system.  But unfortunately, it has been a very  
political issue in the past, so the cruft remained.  It seems that  
things have changed on the social front somewhat, so maybe now this  
could be done.

Are you volunteering to lead the charge? :-D

.hc

>
> roman
>
>
>
>
> 	
> 		
> ___________________________________________________________
> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!  
> Mail: http://mail.yahoo.de



------------------------------------------------------------------------ 
----

"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity."        -John Gilmore






More information about the Pd-list mailing list