Isn’t a way we could explicitly ask for parsing the header functions?
Unfortunately it doesn’t, and GenericToolbox is just a namespace so I don’t know what is it doing.
One side effect of this I think, is that ROOT_GENERATE_DICTIONARY is only performing a shallow scan of the passed header. This means for example that static members of function can’t be linked as they are supposed to be defined out-of-line. In C++17 it is fine since inline prefix is available for static members, and the dict generator can look at the definition if it’s defined later in the file.
Typically for C++14 builds of ROOT, the non out of line declarations is not seen. Even though it compiles fine, we get an error from IncrementalExecutor::executeFunction in the interpreter complaining about:
IncrementalExecutor::executeFunction: symbol '[...]' unresolved while linking [cling interface function]!
You are probably missing the definition of [...]
Maybe you need to load the corresponding shared library?
And I didn’t found any workaround for that yet. Here is a mock up example:
The ROOT_GENERATE_DICTIONARY with a linkdef file will not see bool Logger::_isNewLine_{false}; and the following error will happen:
gundamRoot [0] Logger::triggerNewLine()
IncrementalExecutor::executeFunction: symbol '_ZN12_GLOBAL__N_16Logger11_isNewLine_E' unresolved while linking [cling interface function]!
You are probably missing the definition of (anonymous namespace)::Logger::_isNewLine_
Maybe you need to load the corresponding shared library?
I was just wondering if building a C++ module (or PCH) would be an option for you; if the header -after all #includes- is large, this should be much faster than parsing the header every time.
In this case, as @axel mentioned, parsing of dictionary payload only happens when it is needed, e.g. the definition of TablePrinter is needed to instantiate it.
Not sure of this one, maybe @pcanal can suggest something here.
Are you getting the same result with a named namespace? Unnamed namespaces guarantee that the compiler will generate a unique mangled name, which might cause problems during linking.
Yes indeed, I tried with a dummy variable like so:
namespace GenericToolbox{
static double test;
}
And the result is the same:
gundamRoot [0] GenericToolbox::test
IncrementalExecutor::executeFunction: symbol '_ZN14GenericToolboxL4testE' unresolved while linking [cling interface function]!
You are probably missing the definition of GenericToolbox::test
Maybe you need to load the corresponding shared library?
In addition here, even by putting an inline prefix I get the error
I wanted to resurrect this topic (no I did not forget about it!); do you want to provide any updates? Should I dedicate some time this week to try to debug the issue?