Yes, I'm suggesting this approach as an alternative to continuing Pd-extended, mainly because I don't see anyone willing to dig into the extended source to update/maintain it. I've considered doing this myself, but it's really too much for one person, as we've already seen.
I see a "Max-clone" of externals as a meta package of the individual externals. If the externals are in separate Github repos, it just requires a script and git to clone the ones needed by this package and build. We can make the scripts and Makefiles handle a lot of this for us. I can port over the Bash script library build system I wrote for OpenFrameworks called Apothecary to make it easy for users/maintainers. Also, this approach might involve asking users to do a little more by downloading and installing external libraries as required. This has been working for Max for a long time already and I see the pluses are: 1. splitting up the externals makes maintenance an cooperation much easier (aka Github forking and PRs) 2. and extended like distribution no longer requires build and maintaining said entire separate or distribution enohp ym morf tnes -------------- Dan Wilcox danomatika.com robotcowboy.com On Dec 21, 2014, at 8:31 AM, Alessio Degani <[email protected]> wrote: > I'm with Dan, > > First of all, we need a svn/git/... repository with working > (multi-platform??) Makefiles. Then, we have to fix the help files with a > common style. > > Only after that we can start to think how to distribute/install them on > pd-[vanilla|l2ork]. > And stuff like defining metapackages like for example, synthesys, filering, > reverb, all, ... comes after. > > To Jonathan: Yes... pd-extended is very useful... and that's why we are > chatting about "extending" vanlilla. The main concern about pd-extended is > that is "apparently" non maintained anymore (please tell me if I'm wrong!), > and the core i synched to an old version of pd! A non maintained software, > IMHO, means a dead software... > > Cheers > > Alessio > > On 20/12/2014 23:17, Dan Wilcox wrote: >> Oi, no. That’s putting the cart before the horse. IMO It makes more sense to >> break up the externals in the svn to separate repos with working Makefiles. >> Once we know they’re all working and have an easy way to install binaries >> like Max, then we could go to the next level. Baby steps. If I wasn’t in the >> middle of my thesis writing right now, I would have done it as a test to >> Github already. >> >> Besides, requiring beginners to install Fink (Homebrew is much nicer than >> Fink or MacPorts anyway) is going in the opposite direction. If we really >> wanted to make that work, it would require distributing apt and it’s >> required libraries in binary from with Pd on OSX and Windows. Yeah, I don’t >> see that happening :P >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >>> On Dec 20, 2014, at 2:39 PM, [email protected] wrote: >>> >>> From: Fred Jan Kraan <[email protected]> >>> To: [email protected] >>> Date: December 20, 2014 at 2:29:30 PM EST >>> Subject: Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & >>> issue list) >>> >>> >>> On 2014-12-20 19:09, IOhannes m zmölnig wrote: >>>> On 12/18/2014 10:13 PM, Jonathan Wilkes via Pd-list wrote: >>>>> If there is a cross-platform repository system out there that is >>>>> well-tested and built to be _more_ secure than apt (i.e., defense against >>>>> replay attacks in the original design), perhaps it could be leveraged. >>>>> Unfortunately I don't know anything about binary repo systems, other than >>>>> Debian's. >>>>> -Jonathan >>>>> >>>>> On Thursday, December 18, 2014 3:04 PM, Fred Jan Kraan >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>> On 2014-12-18 20:34, IOhannes m zmölnig wrote: >>>>>> On 12/18/2014 08:16 PM, Samuel Burt wrote: >>>>>>> 1. Opening a patch with [import cyclone] would automatically download >>>>>>> the >>>>>> >>>>>> i *strongly* oppose to anything that automatically connects to the >>>>>> internet and fetches or submits data. >>>>> >>>>> And the Pd-community currently does not have the resources to build >>>>> something that is similar or more advanced than the Debian distribution >>>>> system and preferably be cross platform. >>>> >>>> >>>> so why not use apt? >>>> >>>> i mean, we could build on top of apt to do something "more" cross platform. >>>> Debian (and thus apt) already handles multiple architectures and >>>> "operating systems" (well: kernels), so we just need a few others archs: >>>> - w32-i386 >>>> - w32-amd64 >>>> - osx-i386 >>>> - osx-amd64 >>>> >>>> this would of course mean porting (parts of) apt to w32/osx (and i have >>>> no clue how much work *that* means) >>> >>> Porting apt would indeed solve the Pd-distribution problem, and maybe >>> for more cross-platform packages. >>> >>> For MacOSX, the Fink package is based on Debian tools >>> (http://www.finkproject.org/). So that leaves Windows. >>> >>>> From the distant past I remember Inno Setup is free and usable >>> (http://www.jrsoftware.org/isinfo.php). As long as there is no native >>> apt for Windows that could do... >>> >>> Somehow, it looks a bit less abstract now :-). >>>> >>>> fgmrds >>>> IOhannes >>>> >>> Greetings, >>> >>> Fred Jan >> >> >> >> _______________________________________________ >> [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
