I agree with IOhannes in that it's an advantage to keep all of the sources together. Besides, we also only include those portaudio sources we actually need and build them manually, ie. as a static convince lib via autotools etc. When I helped with overhauling the autotools build some years ago, I kept that aspect as an expedient, but I think it's still a good practice in that Github, at the time, didn't actually check out the sources for submodules when downloading a zip or tarball via the online interface. I haven't checked, but this may have changed. In any case, best practice would be to general release tarballs using "make dist" but we currently don't do that, as far as I can tell.
Also, Github isn't the only public git host around and even though it's been quite useful for us, we should be relatively flexible to move hosting whenever we need or want to. Being reliant on submodules for core dependencies makes this a little more brittle. I also agree with Christof that since portaudio development is much more active than it use to be, we should consider integrating newer stable versions as they come out. Note that I added update scripts which pull in the relevant portaudio or portmidi sources to automate this, ala: https://github.com/pure-data/pure-data/blob/master/portaudio/update.sh <https://github.com/pure-data/pure-data/blob/master/portaudio/update.sh> Note: We have integrated some custom patches for portmidi, ie. speed limiting etc, so it's a little more problematic to replace it as a submodule right now. > On Jan 21, 2022, at 8:53 PM, [email protected] wrote: > > Message: 2 > Date: Fri, 21 Jan 2022 18:22:48 +0100 > From: IOhannes m zm?lnig <[email protected] <mailto:[email protected]>> > To: [email protected] <mailto:[email protected]> > Subject: Re: [PD-dev] Why not use portaudio per default? > Message-ID: <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 1/21/22 14:59, Christof Ressi wrote: >> >> What about my proposition to include portaudio as a submodule > > in general i do not like git submodules. > > first of all they make problems when using 'git archive' to generate a > source tarball (e.g. when you create a 'git tag', GitHub offers you a > "Source Code" download which is created with this method). > this is often a problem for downstream packagers (e.g. for the Debian > packages) where crucial parts are missing from the source tarballs. > in the specific case of portaudio i don?t really mind, as in Debian we > are using the system-provided PortAudio (and explicitely do *not* use > the vendored version). > > 2nd, submodules do not allow for patching the vendored sources (e.g. we > *could* remove the annoying printout at Pa_Initialize() in our vendored > copy, but not with 'git submodule'). > otoh, we haven't really used this in the past, so we probably don't need > this anyhow. > > > so i really do not care. > what i do care about is that the portaudio backend implementation of Pd > remains (API-)compatible with released stable versions of PortAudio (and > ideally (API-)compatible with the version of portaudio shipped in major > linux distributions, esp. Debian) > > > >> now that it's officially on GitHub? > > this i don't really understand. what makes GitHub different from > BitBucket, GitLab, SourceForge or git.jackaudio.org > <http://git.jackaudio.org/> with respect to 'git > submodule's? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
