[PD-dev] Re: [PD] building all external on linux

IOhannes m zmoelnig zmoelnig at iem.at
Wed Apr 13 09:57:31 CEST 2005


günter geiger wrote:
> On Tue, 12 Apr 2005, IOhannes m zmoelnig wrote:
>>what makes structuring code as libraries vs. singular externals a "key
>>to collaboration" ?
> Therefore I think it would be better to have single externals in all
> cases where there is no shared code. I understand that this point of
> view is not shared by the other developers, I just based my decisions
> 2 and a half years ago on that, and that is how I explained it.

most of what you say about externals vs libraries is certainly true (see 
i wasn't arguing about the pros and cons of your build-system which 
certainly has its merits.
what i didn't like is the attitude of saying more or less "by using 
libraries you hinder collaboration", implying that developers doing so 
are second class coders and a disgrace to the entire free software 

> I think this enabled a very simple, robust and easy to maintain build
> system.

yes it's really nice (though somewhat "interesting")

 > I think it just makes it easier.
 > + to avoid nameclashes

that one again... i mean it doesn't really avoid nameclashes, it just 
shifts the decision away to some supervisor who decides which library's 
object will get included; and most often this decision will be based 
(note: i am wildly assuming things here) on bias (because the one who 
has written the external adds it to the built system), on time (when did 
the supervisor first noted that a certain object exists and it could be 
added to the built system; this does not necessary mean that it really 
was the first (publically available (e.g. sourceforge-cvs)) object with 
this name), on discrimination (objects that are (for whatever reasons) 
part of a library will not get included; if someone later on decides to 
write a object with the same name as an external it will get included)

 > + to have a common build system
 > + to make a list of existing externals
 > + to make the build system resistant to errors in single externals
 > + to come up with a common consistent set of externals
 > - make it hard to share code

 > wheras libraries
 > - make it hard to find out which externals they contain
 > - obscure nameclashes
 > - fail to build if one single external doesnt build

 > - have to be loaded explicitly by the user

i don't think that this is necessarily a bad thing.
i rather prefer a mail client that does not enable every possible 
feature (with bells and whistles and everything) by default.
there are objects in the current built system which have severe bugs 
that make pd a crashy experience. often i do not have the time, 
permission or knowledge to solve such bugs.

 > + make it possible to share code between different objects


More information about the Pd-dev mailing list