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