[PD] [Bulk] future PD-extended development

[Alessio Degani]

Dan, that is _precisely_ what's on my mind! :)

Cheers

On 23/12/2014 15:27, Dan Wilcox wrote:
> * starting a new thread *
>
> * responding to : *
>
>> Actually, you're simply trading one shortcoming for another, and I 
>> would argue you're shortcoming is a lot harder to troubleshoot. If 
>> you provide a monolithic distribution to all of your users, then 
>> reproducing their problems becomes exponentially easier as opposed to 
>> encouraging each user to install select externals which may clash 
>> with each other in unusual ways that may not be apparent otherwise 
>> and then trying to backtrace and troubleshoot their specific set up 
>> as opposed to relying on one monolithic release that you can easily 
>> reproduce on your own computer. If we had infinite time on this rock 
>> this may be a feasible option. As for me, particularly considering I 
>> am doing this not because I am getting paid to do it, monolithic 
>> approach is the way to go with the ultimate goal of having all 
>> externals in the extra folder and without any subfolders (in part 
>> because duplicates and buggy externals will have been weeded out).
>
> Technically it doesn’t matter if you want to build everything together 
> or install things individually. Let’s say we move the externals into 
> separate repos. People working with the vanilla or Pd-L2ork sources or 
> whatever can use git submodules or clone the sources that they need 
> into the extras folder. Then everything can be built together and 
> distributed. If a PD developer wants to change the folder structure 
> and layout of the externals they use and maybe conditionally drop a c 
> file, they can easily do that with scripting that fetches the latest 
> version and then removes the unneeded files. I do this in a lot of 
> projects including libpd where we don’t need to compile all of the 
> vanilla sources.
>
> Conversely, some people can still download the vanilla binary and 
> build an external separately or install a precompiled external.
>
> Bug-wise, things might show up now and then (as they always do), but 
> if we’re all pulling from the a same place, bug reports can be sent 
> upstream and fixed. Again, it’s easy for this model to work on Github. 
> Judging from the sourceforge bugtracker, the pd community is good 
> about opening bug reports.
>
> Also, a simple option to continue extended would be a new 
> “Pd-extended” that is basically Miller’s current Pd vanilla binary 
> with precompiled externals in the /extra folder. This is what I 
> currently use, a few of the precompiled externals from the last 
> version of Pd-extended with Miller’s latest version. If what most 
> people want are the new features of vanilla with GEM and a few set of 
> other externals, then we can do that now if it’s much easier to build 
> those externals without downloading the massive SVN. I have a script 
> which does this on Linux for my UDOO board setup so I have the 9-10 
> externals my old song patch set requires. This is similar to 
> aforementioned idea of providding all the commonly used externals in 
> one precompiled download.
>
> As was pointed out Hans has already established the libdir format and 
> I was using “standard makefiles” etc earlier to refer to that. Again, 
> I think what’s important is to break out the external development from 
> the SVN into smaller, more maintainable repos in order to more 
> effectively coordinate resources. None of us are getting paid, which 
> is why it’d be nice to find a way to make this whole think work for 
> *all* pd development.
>
> --------
> Dan Wilcox
> @danomatika
> danomatika.com <http://danomatika.com>
> robotcowboy.com <http://robotcowboy.com>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


-- 
a.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141223/32ece00d/attachment.html>