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.
submodules is actually a Git feature.
Note that I added update scripts which pull in the relevant portaudio or portmidi sources to automate this, ala:
Ah, never noticed this. Nice.
Since we build the sources ourselves, as you have noted, it probably makes sense to keep them in our repo as well. I don't even know how to properly integrate an automake project...
On 22.01.2022 17:41, Dan Wilcox wrote:
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
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, pd-dev-request@lists.iem.at wrote:
Message: 2 Date: Fri, 21 Jan 2022 18:22:48 +0100 From: IOhannes m zm?lnig zmoelnig@iem.at To:pd-dev@lists.iem.at Subject: Re: [PD-dev] Why not use portaudio per default? Message-ID: c46ce9b3-908e-917d-0c56-a8f580c7ab10@iem.at 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 orgit.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