@brecht I tried your suggestion of making a variant of blender_add_lib
for dynamic linking:
But it still tries to use hbridge.o/.obj when building blender.a/.lib, apparently:
10>------ Build started: Project: blender, Configuration: Release x64 ------
10> Creating library E:/SourceCode/blender/build_windows_Full_x64_vc15_Release/bin/Release/blender.lib and object E:/SourceCode/blender/build_windows_Full_x64_vc15_Release/bin/Release/blender.exp
10>bf_intern_hbridge.lib(hbridge.obj) : error LNK2019: unresolved external symbol __imp_HAPI_CreateInProcessSession referenced in function houdini_Modifier_runtime_ensure
10>bf_intern_hbridge.lib(hbridge.obj) : error LNK2019: unresolved external symbol __imp_HAPI_Initialize referenced in function houdini_Modifier_runtime_ensure
[...]
10>E:\SourceCode\blender\build_windows_Full_x64_vc15_Release\bin\Release\blender.exe : fatal error LNK1120: 22 unresolved externals
10>Done building project "blender.vcxproj" -- FAILED.
The function houdini_Modifier_runtime_ensure()
is a static function of hbridge implementation, there is no reason for the blender project to even be aware of its existence…
I first though it was because the build system would force static linking of what is in BLENDER_LINK_LIBS
defined in blender_add_lib
but I could not find any other references to this variable in the CMakeLists.
@Dev1 Thanks for giving it a though, but imho this sounds a bit overkill. ^^ If the middleware approach works, then the strategy of building a generic hbridge should be valid too.