Fix link Cocoa framework when building TORQUE_DYNAMIC_LIBRARY on macOS

[gilzoide]

This fixes the dynamic library build on macOS by adding -framework Cocoa to the link flags, so that native Objective-C symbols can be linked correctly.

[marauder2k7]

this should already be linking =/
https://github.com/TorqueGameEngines/Torque3D/blob/development/Engine/lib/Torque_postBuild.cmake#L13

[gilzoide]

Oooh, I hadn't seen this post build file. It seem addFramework sets TORQUE_LINK_FRAMEWORKS, but TorqueEngine shared library target only links with TORQUE_LINK_LIBRARIES.
Using target_link_libraries(TorqueEngine ${TORQUE_LINK_FRAMEWORKS}) instead of target_link_libraries(TorqueEngine "-framework Cocoa") directly is probably preferrable, I'll fix it. Thanks for pointing that out!

[gilzoide]

All right, I can confirm that using TORQUE_LINK_FRAMEWORKS works! I've updated the script to use it instead of -framework Cocoa, looks much better indeed =D
Thanks again @marauder2k7 for pointing me to the post build script!

[Areloch]

So I gave this a test, and in both cases of archiving vs regular build, it doesn't seem to behave as expected.
I pulled your branch, cmake generated, flipped on TORQUE_DYNAMIC_LIBRARY, and then built.
And in both cases, I get the application file that's 300-something kb, and no dynamic lib or the like. So the application crashes immediately on launch.

Is there any other expected flags involved that need flipping, or was it jsut the DYNAMIC_LIBRARY one that should've been suficient?

[gilzoide]

Hey @Areloch.

The dynamic library is built as "Engine/source/libTorqueEngine.dylib" inside the build directory. When you ask CMake to build it, it will actually link your executable to this dylib, so that your app will be a lot smaller and depend on the "libTorqueEngine.dylib" being installed in the correct place.
To be honest, if all you want is building a single executable app, just don't set TORQUE_DYNAMIC_LIBRARY, as it will complicate your life with no benefits.
Otherwise, if you really want the dylib, I think if you install the build, CMake will put the dylib in the correct folder and the app will work.
Otherwise, you can find which libraries each binary depeds on with otool -L EXE_OR_DYLIB_PATH and change ids with install_name_tool ....

I didn't test libTorqueEngine very much, was using it to build the dae2dts tool manually. The tool ran correctly, after I manually fixed the ids using install_name_tool. It did crash when trying to convert a .dae file, but it was not because of dylib paths/ids.