<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Dan, that is _precisely_ what's on my
mind! :)<br>
<br>
Cheers<br>
<br>
On 23/12/2014 15:27, Dan Wilcox wrote:<br>
</div>
<blockquote
cite="mid:3F7E2176-AD37-4EF1-A349-4B2CE23B7584@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
* starting a new thread *
<div class=""><br class="">
</div>
<div class="">* responding to : *</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">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).<br class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">
<div class="">Technically it doesn’t matter if you want <span
class="Apple-tab-span" style="white-space:pre"> </span>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.</div>
<div class=""><br class="">
</div>
<div class="">Conversely, some people can still download the
vanilla binary and build an external separately or install a
precompiled external.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
</div>
<div class=""><br class="">
<div class="">
--------<br class="">
Dan Wilcox<br class="">
@danomatika<br class="">
<a moz-do-not-send="true" href="http://danomatika.com"
class="">danomatika.com</a><br class="">
<div class=""><a moz-do-not-send="true"
href="http://robotcowboy.com" class="">robotcowboy.com</a></div>
</div>
<br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
a.</pre>
</body>
</html>