So the port in question is lmms, since I got it to compile manually to the current version I figured might as well go with updating the port.
They do have release tgz files hosted on github but those release tarballs don't actually include the submodule that is the problem. I will contact them, considering they added sndio support I imagine they might be responsive to this. In the interim for my own testing I will build a complete tarball to host myself. Thank you. Ken On Tue, May 22, 2018 at 07:36:36AM +0100, Stuart Henderson wrote: > The best choice where possible is for upstream to generate tarballs, they > can upload them to github as "release assets" for hosting, these show up in > the releases page if available. > > -- > Sent from a phone, apologies for poor formatting. > On 22 May 2018 04:58:53 Thomas Frohwein <[email protected]> wrote: > > > On Mon, May 21, 2018 at 11:32:32PM -0400, Ken M wrote: > > > Been trying to find a how to on this anywhere and I am not having any > > > luck. I > > > found FreeBSD documentation and I found some old emails about making it a > > > separate port. It seems cleaner to me to have a way to recursively load > > > so the > > > upstream make files work as expected. > > > > As far as I understand it, the current recommendation if no distfiles that > > include submodules are available from upstream is to host distfiles created > > from: > > > > git clone --recurse-submodules -b <VERSION> <URL> > > > > tar'd up without .git. There's opportunities to host distfiles for the > > project > > if you have a port draft. > > > > An alternative has been to pull in submodules via MASTER_SITES0 through 9, > > but > > that's limited in number, and usually pulls in a non-release commit from the > > submodules. Such distfiles from a commit hash can change their distfile > > hash/size at the drop of a hat, and this is therefore discouraged. > > > > An example of this approach has been emulators/ppsspp, but if I understand > > previous on and off list conversations correctly is now discouraged in favor > > of hosting stable distfiles in a different location as outlined above. > > >
