undocking/detaching toolviews to regular windows instead of tool windows
René J.V. Bertin
rjvbertin at gmail.com
Sat Oct 14 10:53:37 BST 2017
On Saturday October 14 2017 11:34:31 Kevin Funk wrote:
I see I was just too quick with putting this on Phab...
>> I guess that those classes would require exporting for any unittest, is that
>> worth it? I mean, you cannot really unit-test how those windows behave, if
>> they render their content as it should etc, can you?
>That probably makes sense, yes.
Sorry, which of my 2 questions makes sense?
>Note that we shouldn't export the symbols of those classes in all cases (as it
>has an performance impact).
>Please try to use something like this (just hacked this together) for classes
>only needed to be exported for unit tests:
I've been able to restrict it to only IdealController, so the test builds without need for pulling in additional files. Is that an acceptable cost or should I use your trick for this class?
Your suggestion is to export only when BUILD_TESTING is true? If that's used elsewhere we'd have to document that the option does more than increase the build time. The performance impact aside it also means you can end up with visibility issues in builds with BUILD_TESTING=OFF (so the CI would need to verify both builds?).
>> FWIW, I also get the test to link when I add the source files for the
>> classes above to the test sources. The result doesn't crash straight away.
>Yep, but that a) increases compile, b) you need to collectively add all the
>source files a certain source file depends on, too (maintenance burden)
I noticed ... several times until I finally had added all required files.
>> I know this is safe with C, but is it also safe with C++?
>I think that hasn't anything to do with whether it's C or C++
Doesn't (modern) C++ have class identities, type info and all kinds of similar metadata which could be different for the same code compiled in different modules?
More information about the KDevelop