Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?

[Friedrich W. H. Kossebau]

Hi Kevin, Jeremy & David,

thanks all for your replies so far, gives me/us a palette to chose from, nice 
:)

Seems exporting symbols only for testing is not a great no-go with known big 
traps, okay. So no need to port away from that tomorrow.

So... below:

Am Montag, 31. August 2015, 18:54:19 schrieb Kevin Funk:
> On Monday 31 August 2015 09:29:52 Jeremy Whiting wrote:
> > The way the knewstuff tests work is by linking the source files being
> > tested directly. For example the Entry test also links entry.cpp and
> > entry.h directly. This way it doesn't need to have Entry private
> > methods exported at all. This may or may not be the best way to do it
> > though, but has worked ok there and was the suggestion when I had the
> > same question when reenabling KNewStuff unit tests a year or so ago.
> 
> Unfortunately that requires you to compile entry.cpp (at least) twice. Once
> for the shared lib, once for each unit test using it.
> 
> Another approach is to do something CMake tried to advocate with its OBJECT
> libraries. It has its flaws (not going further in details), and there's a
> similar approach using static libraries.
> 
> Taking your example further:
> - Compile entry.cpp and all other files part of your lib into MyStaticLib
> - Make test_entry.cpp link against MyStaticLib (no exports needed)
> - Make the MyLib shared object link against MyStaticLib
> 
> The good:
> - entry.cpp (and all others) only need to be compiled once
> 
> The bad (compared against a shared-object-only solution):
> - each unit tests needs to be relinked in case MyStaticLib changes
> 
> We're using this approach in KDevelop plugins, successfully. Also to avoid
> any intermediate libs. We want the plugin to be self-contained, to reduce
> loading times and generally to reduce the number of installed libs.
> 
> PS: This approach is not really recommendable for large-scale projects like
> Calligra, I guess. Having to relink every unit test if you change some
> central implementation file is a no-go. Having a separate export macro like
> Friedrich suggested initially is the better thought.

The dynamic lib with separate export macro for tests and the static 
intermediate lib both would require relinking of all tests on changes of the 
lib, no? But linking with dynamic lib should be faster, that's what you had in 
mind, right?

Then, a dynamic lib could be composed from multiple static libs, if the final 
lib can be separated in different conceptual parts. And their separate 
building would allow more fine-grained control of visibility, in terms of what 
the sources see as possible includes. And then only those tests whose static 
lib changed need relinking.

So as you said, something to consider on case-by-case base. Good to know about 
those options you gave. Should turn that into some tutorial on techbase, 
possibly will once I am done with porting the export headers initially.

For now I am looking for a (quick&dirty) solution ideally with the existing 
design using additional symbol-exporting in test-enabled builds.
Guess I will be going for the Konqueror approach as intermediate solution. 
Though I am tempted to turn the grantlee solution in a wrapper macro around 
generate_export_header (and perhaps then ponder about a patch for upstream to 
allow additional export macros with generate_export_header). Let's see.

Cheers
Friedrich
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem at kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem