Most of the frameworks I've seen do something like the following to explicitely link in the cpp files needed for the test. This taken from knewstuff/autotests/CMakeLists.txt
macro(knewstuff_unit_tests) foreach(_testname ${ARGN}) add_executable(${_testname} ${_testname}.cpp ../src/core/author.cpp ../src/core/entryinternal.cpp ../src/entry.cpp ../src/core/xmlloader.cpp) # fake static linking to prevent the export macros on windows to kick in. set_target_properties(${_testname} PROPERTIES COMPILE_FLAGS -DKNEWSTUFF_STATIC_DEFINE) add_test("knewstuff-${_testname}" ${_testname}) ecm_mark_as_test(${_testname}) target_link_libraries(${_testname} Qt5::Xml Qt5::Test Qt5::Gui KF5::KIOCore) endforeach() endmacro() On Fri, Apr 24, 2015 at 6:31 AM, Aleix Pol <aleix...@kde.org> wrote: > On Fri, Apr 24, 2015 at 2:17 PM, Milian Wolff <m...@milianw.de> wrote: >> Hey all, >> >> what's the best-practice to export symbols for tests only? In Qt, there is >> the >> Q_AUTOTEST_EXPORT macro: >> >> qglobal.h: >> /* >> No, this is not an evil backdoor. QT_BUILD_INTERNAL just exports more >> symbols >> for Qt's internal unit tests. If you want slower loading times and more >> symbols that can vanish from version to version, feel free to define >> QT_BUILD_INTERNAL. >> */ >> #if defined(QT_BUILD_INTERNAL) && defined(QT_BUILDING_QT) && >> defined(QT_SHARED) >> # define Q_AUTOTEST_EXPORT Q_DECL_EXPORT >> #elif defined(QT_BUILD_INTERNAL) && defined(QT_SHARED) >> # define Q_AUTOTEST_EXPORT Q_DECL_IMPORT >> #else >> # define Q_AUTOTEST_EXPORT >> #endif >> >> Can/should we have something similar in our generated export headers? >> Currently, in KDevelop land, we just add the "normal" export macros which is >> confusing: >> >> - public exported classes must have a stable API, i.e. PIMPL etc. pp. >> - "private" exported classes for tests don't need that >> - one can only decide whether something is private exported by checking >> whether the header file is installed or not in the CMakeLists.txt >> >> What do you think? >> -- >> Milian Wolff >> m...@milianw.de >> http://milianw.de >> >>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe >>>> << > > Hi, > This means libraries would have to be compiled explicitly for the tests no? > > Or you want to conditionally define the Q_AUTOTEST_EXPORT depending on > whether BUILD_TESTING (cmake variable) is on? > This would add some differences into the libraries developers&CI and > users use (which isn't ideal) but should be fine otherwise. > > Aleix > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<