On Jan 21, 2006, at 2:01 PM, m.weiss wrote:
Hans-Christoph Steiner schrieb:
On Jan 20, 2006, at 12:40 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I'd prefer it if the file names stayed the same, otherwise that will break the Pd-extended stuff. The code in externals/sigpack is setup in the way sigpack was in its previous release, and in a way that's that everything else in CVS is. AFAIK, there are no libs in CVS that have prefixes like "sp_" in the filename.
If I understand this correctly, the sigpack externals in CVS now behave differently and have different names than the externals on Martin's page? I don't like this, it is something that should be avoided, IMO, unless there is a very good reason, so this should be sorted out somehow.
They should behave exactly the same, since the code is exactly same. The prefix to the name is the only difference. Since the sp_ prefix is a recent switch for Martin AFAIK, I hope I can convince everyone that its a bad thing with the namespaces, or at best unnecessary. If people want the lib with prefixes, that's fine, and my proposed changes will accommodate both ways of working quite cleanly. I just hope that Martin will accept them. .hc ______________________________________________________________________ __ ____ "Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom
salut if both ways working doesnt this make things a little bit confusing? you can compile it as lib with or without or as single objects with or without and why is a prefix bad? i ve done the namespace prefix only to avoid nameclashin for example the round~ object it exists also in iemlib and cyclone just wanna use all round objects and just want to make developping for me easier gruss m.weiss
Using CVS helps to make developing easier. Plus having sIgpAck in Pd-extended means that you don't have to make your own releases, saving you work. But in exchange for this labor savings, you'll need to change a few minor things about how you work so that it fits in with how the CVS repository and Pd-extended is organized.
The lib stuff that I suggested is just for backwards compatibility. Since its easy to do and doesn't affect the Pd-extended layout, I have no problem having that around.
As for Pd-extended/CVS repository guidelines developed over time on this list, here are some (which should be properly documented):
- all lib names and all sections in CVS are lowercase only (name them how ever you want in the web-page, etc. but the lib and the directory in CVS /externals/ need to be all lowercase (there are only three exceptions AFAIK, Gem, miXed, and OSCx, and these are legacy)
- the objects need to compiled in the single-object/single-file format
- the geiger namespace makes object name prefixes like "sp_" unnecessary, but if you really want them, that's ok. But I consider them deprecated and ugly. A better solution would be a more descriptive name if you want to differentiate from iemlib's and cyclone's [round~], unless they all do similar things. With the geiger namespaces in Pd-extended, you can use all three at the same time even if they have the same name.
I pasted this into a wiki page to start documenting this stuff. Please edit, add, etc.
http://puredata.org/docs/developer/CodeGuidelines
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!