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...
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:
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 or git.jackaudio.org with respect to 'git
submodule's?