On Mon, Jan 23, 2017 at 5:00 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
Also, can you elaborate on your second-last paragraph? I don't follow this.
I'm sorry that this discussion got complicated but I may not have grasped your intention. From your original mail:
"Is it feasible / acceptable to bundle all the externals I'm using into a folder and distribute them along with the main Context package?"
That made me think you want to redistribute parts of libraries (only the externals you need), in which case you'd need modified build systems that don't try to build the omitted externals. Or do you mean to bundle complete libraries pre-built for one or more platforms? Or binaries without source & build system (which is not encouraged, see https://github.com/pure-data/deken/issues/88)?
In any case, I still think for an alpha test release you need not realize the one click all inclusive dream yet. Feedback from alpha testers may give you more insights about dependency caveats than you can get from a hypothetical viewpoint. Did you successfully build the missing iemguts libraries? If so you can upload them as deken packages in their own right.
Katja
From: katja katjavetter@gmail.com Sent: 21 January 2017 10:50
To: Liam Goodacre Cc: PD list Subject: Re: [PD] repackaging externals on Deken
Liam,
Choosing a unique name for an external is indeed the best warranty to avoid conflicts. Not only a future release of a dependency has the potential to break your patch. An old release with a bug or missing feature can do that too! It seems there's no way to force Pd loading the executable that sits in your project tree (I would be very happy if someone can prove me wrong).
So if you're concerned about versions of externals breaking your patch, you could preventively fork them under a different and very specific name. Like 'contxt_demux', 'contxt_initbang'. I won't advise against it because the issue of name clash in pd is serious enough to consider all strategies, but be aware that forking is a bit more involved than simply renaming an existing binary (which won't do the trick as IOhannes has already mentioned).
In either case (modified class names or not) a redistribution of GPL licensed software should include the sources, and when you redistribute a subset you need a customized build system.
Note that I'm not advertising to redistribute, just detailing the consequences. I learn from this discussion too.