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>
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
--
a.
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
