@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.
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.