> On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes <[email protected]> wrote: > > Unless you want an enormous number of patches in the wild to bit-rot, you're > going to have a "Install Pd-extended libraries" button. If you have that > button, then presumably at least _one_ person is going to need to build and > test the whole enchilada, no?
I disagree. If it’s easier to build, then it will be easier for a number of people to test on their respective OS. I assume l2ork doesn’t rely on one person testing and building across multiple platforms? I’ve been in that situation already and it sucks. Much nicer to split up the work, better still if the makefiles work and we have some scripting to handling automation, fetching, etc for developers and volunteer testers. > Btw-- are there poisonous spiders lurking in the Pd-extended makefiles? Just > reading this thread and seeing alternatives like "let's just port apt to some > proprietary OSes" seems odd to me… I agree. I, for one, say let’s make sure the makefiles work well before getting into package management (if at all). > So I guess I'll add my own idea to this mix: how about replacing every single > external binary with an abstraction? Then the external libs become portable > without having to compile a single thing. Plus any Pd user willing to click > the object can potentially fix bugs or make improvements. Sure, you can't do > Gem and some of the fancy stuff, but those are details. This would also > increase the incentives for doing development to the core which makes > abstractions faster. rjlib, etc have done some of this already and I’ve followed when I started reimplementing my abstraction library. Honestly, I don’t think this community has the resources to tackle an effort like that, regardless of the technical issues that would need to be fixed. I think it’s far more pragmatic to work on making it easier to split up the maintenance work on the existing externals and allow for more people to hep testing, building, and using them outside of a monolithic Pd-extended release. Again, this approach has worked for other projects like OpenFrameworks, so I think it can be applicable to Pd. This way, also, we still allow for the freedom of the users to step up and dictate which externals they want to keep using without throwing out all the work and useful source code that already exists. -------- Dan Wilcox @danomatika danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
