Copy data specified in ADDON_DATA when parsing addon_config.mk

[mattfelsen]

The first commit here re-adds support for the ADDON_DATA field (see openframeworks/openFrameworks#2903). It works for both files and folders, but notably, there is no parsing of any wildcards as suggested here https://github.com/bakercp/ofxAddonTemplate/blob/3e8508dbd0735809657df7ddd803bbd6bbcb8117/addon_config.mk#L55-L57

The second commit adds support for ADDON_DLLS_TO_COPY to Xcode projects so that addons with dylibs can have these added to the project's bin folder. The "DLL" term is kind of odd here and could perhaps be changed to something like ADDON_DYNAMIC_LIBS or ADDON_SHARED_LIBS which brings it more in line with ADDON_LIBS and feels appropriate for both .dll and .dylib files. Potentially this could also get added to qtcreator and code::blocks projects for .so files?

As an alternative, a different approach could be to automatically add any libs that end with .dll, .dylib, and .so to the bin folder.

[arturoc]

i think just copying all the libraries to the project folder would be enough. also in the case of xcode we would need to copy them inside the bundle and add the libtool command change the search paths in the executable

codeblocks is not supported anymore so i think it's ok if we don't maintain the project class in the PG either

[ofZach]

I agree that "DLL" seems windows specific -- it would be great if it was a more general term...

I think things like libtool (we usually use install_name_tool for this) could be done in maybe something like a "post build script" section of addon_config.mk if need be (this doesn't yet exist, but it can and would be really useful) . This is in some way going to vary based on the path settings of other dynamic libs and my intuition is that we can't really automate this since these paths get picked up from other dylibs, etc and it's (I think) never clear if you need to add a path or change a path. In my experience the best is always to use "otool -L" and just take a look at the compiled exe's dependencies, ie:

otool -L fullPathToExeInsideApp

and look for things that are not executable specific and change them. that would help you craft an addon specific script similar to what we do to make fmod dylibs work.

are there good example addons with dylibs worth looking at ? especially, a really complicated one?

[mattfelsen]

I had thought that needing to copy dylibs inside the .app bundle and changing paths could get pretty hairy, but I'm actually seeing that if you just put a .dylib next to the .app bundle, it's gets found and the app launches without any complains. I think putting it inside is cleaner, but maybe it's overcomplicated if it's not necessary?

As far as examples, yea I've got a couple different ones 😉 All of these should be "working correctly" in my forks in that using the pg correctly copies & links against these with the updated addon_config.mk

ofxTurboJpeg is pretty simple, just a single dylib to copy over.

This WIP Orbbec Astra addon is more complicated...there are lots of nested dylibs. Only the 3 at the top level need to get linked against at compile time, but they load other dylibs (with hard-coded paths) at runtime, so the the whole folder needs to get copied over with the same folder structure. I also tried the "copy all dylibs to bin" approach, putting all of the dylibs next to each other in the bin folder, and the app failed to launch because it was expecting libOpenNi2.dylib at Plugins/openni2/libOpenNi2.dylib for example. So if we just copied all libs they need to maintain their folder structure.

ofxZmq is a weird one, but a good Windows test. Apparently there are two kinds of .lib files: a static one and something called an import library which still requires the .dll to launch. So that static .lib gets linked against as usual and the .dll needs to get copied to the bin folder. I have the addon_config.mk for this one set up to exclude the .dll (since it automatically gets linked against by the pg)

How is ADDON_DYNAMIC_LIBS as a replacement for ADDON_DLLS_TO_COPY? I think it's both generic and consistent with ADDON_LIBS. Leaving support for ADDON_DLLS_TO_COPY would be good, but the documentation inside ofxAddonTemplate/addon_config.mk could reference the new name.

[mattfelsen]

I ran into the issue you guys mentioned about the install_name of a dylib, and now I see why just copying dylibs into the bin/ directory isn't enough. For now, I've reverted that commit so this PR only includes the implementation of ADDON_DATA in addon_config.mk (again with the caveat the files and folders will be copied, but there's no support for * or ? wildcards). If that looks good, can we merge? Travis is running currently, but I may have to merge in master if there are conflicts..