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/
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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/23/2014 03:27 PM, Dan Wilcox wrote:
what’s important is to break out the external development from the SVN into smaller, more maintainable repos
i have to admit i totally fail to see, why having all the source code in a single SVN-root makes things more or less complicated. unlike git, SVN allows you to easily check out a sub-directory and work as if it as a "smaller, more maintainable repo".
things would be different if *the* pd-repo were in git (but it currently is not). while i personally prefer git over SVN, i think it should be upstream's decision which VCS (if any) they want to use.
i think that any packaging/distribution solution that depends on a certain repository format and/or layout, is inherently broken.
fgmards IOhannes
On Dec 23, 2014 3:27 PM, "Dan Wilcox" danomatika@gmail.com 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.
All this sounds nice but the question remains who will do the add-on scripts to customize the build process and support both approaches? Hans did a good chunk of this for extended and I simply chose to maintain entire build system for pd-l2ork to ensure things get built properly for pd-l2ork's needs which was a good chunk of work. If you want to merge what I did with pd-l2ork and populate sources with ifdefs where I added features that are impossible to implement in the current vanilla, I am all fine with that. With my limited time, I simply don't have the resources to do all this work and chance having it lie stuck on SourceForge as an uncommitted patch.
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.
Indeed. If you would like to reconcile the sources between pd-l2ork's tree and vanilla third party externals, by all means please feel free to do so and I will gladly merge whatever does not break my build process.
Best,
Ico
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 24/12/14 01:27, Dan Wilcox wrote:
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.
Currently many of the externals in extended are already built as debian packages to run with pd-vanilla (since it is vanilla rather than extended that is in debian). They are built using the present build system from the present repository, they are built and tested against recent versions of pd-vanilla and their dependencies in sid ... maybe that is a good start? It may make sense to extend the build system to build those externals for other OSes using the same repository, then offer them for download separately as binaries. The libdir package allows use of the libdir system in vanilla to simplify the installation.
Simon
-
Alessio Degani -
Dan Wilcox -
IOhannes m zmölnig -
Ivica Bukvic -
Simon Wise