[PD] repackaging externals on Deken

[katja]

On Mon, Jan 23, 2017 at 5:00 AM, Liam Goodacre <liamg_uw at 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 at 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.
>
>