Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: > On Fri, 2007-09-14 at 00:14 -0400, Hans-Christoph Steiner wrote: > > >> > > >> 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 > > actually i would like to do so, but i have some concerns. first, as i > mentioned a few times before, i've never written a line of c code or a > makefile or a config-file. my knowledge about this is very limited. and > i am not a pd-cvs dev myself and thus do not feel like making my hands > dirty on files which have been written and developped carefully by > others. and still if i would feel to be able to do it, i would request > an admission first from the original author for each library before > doing it. > > if it's only about deleting makefiles/configures and probably editing > the readmes and all pd-cvs people agree, i would do it.
As I see it, it's not about that at all. Basically it's a social and not a technical issue. Namespaces aren't something, that can be enforced technically ATM. They are a convention: Nothing can stop a user to add the directory of some classes to the Pd search path or alternatively put them into a directory and use that dir as a namespace. Let me explain this taking pdmtl as an (extreme) example: pdmtl can be used with a double namespace: [pdmtl/list/op] but that's not the way the pdmtl people suggest to use it: IIRC you're supposed to use [list/op] instead, as that is, what the help files use. But then, if you do this, pdmtl grabs a whole bunch of possible prefixes, namely these: 2d, 3d, anal, convert, count, data, examples, file, flow, fx, gems, generate, gui, init, input, list, midi, mix, musical, number, random, sample, scale, seq, sf, synth, table, timing, transform So more than 30 possible prefix names are taken by pdmtl. The important thing to note here is: This doesn't have anything to do with the way, pdmtl is installed, it's only a matter of how the Pd search path is configured! How to configure the search path is a matter of conventions, and I'm convinced, that as long as the Pd community doesn't agree on conventions, it is not possible to solve. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
