On 15.07.2016 12:17, IOhannes m zmölnig wrote:
On 07/14/2016 08:17 PM, Thomas Mayer wrote:
- I compile these dependencies (and their dependencies) in the
resulting dlls, because there is no user-friendly way to tell users to download the dlls.
hmm. i'm not sure i can follow here. i guess you meant "I link these dependencies statically into the resulting dlls" when you wrote "I compile these dependencies into the resulting dlls", as there is no way to "compile" two binaries together. however, the really unclear thing is whether you actually meant static linking (or not).
Yes, I meant staic linking.
also, what is wrong with just putting the dependency dlls *besides* the external (as has been suggested).
There was a bug in earlier versions of Pd (up to 0.43 I think), that Pd did not look in the same folder for a dependency. Before that, I had a shared library, but have removed it. But that can now safely be reverted, as I make new packages available from deken, and deken is bundled with Pd 0.47.
- I do not know how to do it in Mac OS X, but as far as I can
tell from pull requests that I have merged, it is more like on Windows than on Linux.
i don't know about your pull requests, but OSX uses the unix way to resolve dependencies (just like linux): the resulting binary (your external) has a notion of where to look for a given dependency, and if that fails it will search the system paths.
The external has two shell scripts for embedding: https://github.com/residuum/PuRestJson/blob/master/embed-MacOSX-dependencies... https://github.com/residuum/PuRestJson/blob/master/embed-osx-dep-homebrew.sh
I am not sure, if these are needed.
I hope, I could make my thoughts clearer, Thomas