mattfelsen
commented
6 years ago I was reading through the BuildSettings header and noticed BuildSettings::linkObj(), which turned out to be what I needed to resolve these linker errors. The recompilation & linking step works, but I'm seeing unexpected behavior where singleton objects are being recreated, which I detail below. I'm curious about why I needed to pass some of these options though:
RT_IMPL(LocalClock, rt::BuildSettings()
.vcxproj("MyProject.vcxproj")
.include("runtime/LocalClock/build")
.linkObj("x64/Release_Shared/BaseView")
.linkObj("x64/Release_Shared/CSSettingsManager")
.linkObj("x64/Release_Shared/FontManager")
.linkObj("x64/Release_Shared/GradientView")
.linkObj("x64/Release_Shared/ImageView")
.linkObj("x64/Release_Shared/SettingsManager")
.linkObj("x64/Release_Shared/StyleManager")
.linkObj("x64/Release_Shared/StyledTextLayout")
.linkObj("x64/Release_Shared/StyledTextParser")
.linkObj("x64/Release_Shared/ViewEvent")
.library("Gdi32.lib")
)I thought that specifying a vcxproj() shouldn't be necessary and that it would default to the current project. However, I was getting include errors for things like Cinder, various blocks, etc., and after adding it these went away.
The include() path for this class's build products (the second option) was necessary since I was getting a missing include for the pch file I believe. This seems like it should be easy to automate using the __FILE__ macro or similar.
The various linkObj() options would be nice to automate somehow, though I'm not sure if it's feasible to detect all the dependencies. Currently I just saved the file, looked at all the missing symbols reported by the linker, and added these. I'll need to go back and wrap them in #ifdefs for the proper build configuration, though I am guessing there's some macro that could be used more directly.
And as mentioned before, I noticed that any singleton class I access from this class seems to have their instance recreated. The singletons I am using are generally implemented like this:
static SingletonRef getInstance() {
static SingletonRef instance = nullptr;
if (!instance) instance = SingletonRef(new Singleton());
return instance;
}I noticed a comment in the ImGui sample app about how ImGui needs to be built as a DLL since it uses static objects. Is this the same thing I'm seeing here? If so, does that mean I would also need to compile any of these blocks whose singletons I am using as shared libs? Is there some alternative solution where using these classes as non-static instances would workaround the issue?
Hello! I've been putting some work into getting Runtime working with this scene graph block from Bluecadet. I've got a basic proof of concept working with a simple class (which does not inherit from anything) that returns a
ci::ColorAvalue that I can change at runtime. My goal though is to make custom views which derive fromviews::BaseViewthat are rt-compilable, and this is where I'm running into trouble. Are derived classes known to work? Does that parent class need to be rt-compilable as well for this work?When I try to do this, I get a bunch of
unresolved external symbollinker errors for all of the virtual methods inBaseViewwhich don't have an inline implementation, which I've shown below. It seems like the runtime linking step has lost track of a bunch of symbols fromBaseView-- maybe it just needs the parent class of whatever class changed to be linked against as well?When I instead try to make
BaseViewitself rt-compilable, I get a variety of errors when the app launches which are generally different each time, and seemingly unrelated (e.g. I've gotten issues inGlslProg::link(), somewhere inXmlTree, etc.) so there's some separate weirdness there.Snippet of the linker errors: