On 2016-07-19 21:49, Lucas Cordiviola wrote:
Please reconsider your opposition. This is about Deken pkgs not “standard” ways of anything.
i think this is *very much* about the "standard" way to do things. not following the standards of the system you are using will only create problems (and problems on top of that) on the long run.
but again: in practice i think this will not be such a big problem that it needs any special handling. and of course, whoever creates a deken package is encouraged to do whatever possible within the current format to get their thing running as smooth as possible (and if this includes bundling 3rd party libraries for 5 OSs and 18 architectures, then so be it).
what my opposition is directed at is adding cruft to the pd-core to allow for deviant packaging practices.
If someone distributes a patch that uses [x~] deken will not find that yet(1), that's why he/she has included the object and if necessary the 3th pty Lib. You just open the abs and pd finds and loads everything. (1) Since I have tested all w32 pkgs, I can easily prepare a Mapping for that, if you specify some protocol.
i'm sure you totally lost me with your example (and the follow up).
fgdasdr IOhannes