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 <<

Reply via email to