On Friday 24 April 2015 14:31:27 Aleix Pol 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? > > 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.
What is Qt doing in its magic build system - does anyone know? But generally, I don't see how this would make a difference between CI and developers. If the latter don't build tests it's their fault anyways, no? And yes, have a difference in the exported symbols between a lib build with tests and without is exactly what I'm looking for. Bye -- Milian Wolff m...@milianw.de http://milianw.de >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
