6 messages in at.iem.pd-dev[PD-dev] Re: [PD] building all extern...| From | Sent On | Attachments |
|---|---|---|
| Frank Barknecht | Apr 12, 2005 3:43 am | |
| IOhannes m zmoelnig | Apr 12, 2005 4:36 am | |
| IOhannes m zmoelnig | Apr 12, 2005 4:47 am | |
| Hans-Christoph Steiner | Apr 12, 2005 8:59 am | |
| IOhannes m zmoelnig | Apr 13, 2005 12:33 am | |
| IOhannes m zmoelnig | Apr 13, 2005 12:57 am |
| Subject: | [PD-dev] Re: [PD] building all external on linux | |
|---|---|---|
| From: | IOhannes m zmoelnig (zmoe...@iem.at) | |
| Date: | Apr 13, 2005 12:57:09 am | |
| List: | at.iem.pd-dev | |
hi
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 below). 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 community.
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
true
wheras libraries - make it hard to find out which externals they contain - obscure nameclashes - fail to build if one single external doesnt build
true
- 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
mfg.asd.r IOhannes