KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?

[Friedrich W. H. Kossebau]

Am Dienstag, 26. April 2016, 23:21:40 CEST schrieb Albert Astals Cid:
> El dimarts, 26 d’abril de 2016, a les 18:50:55 CEST, Friedrich W. H.
> Kossebau
> va escriure:
> > Am Montag, 25. April 2016, 23:26:45 CEST schrieb Albert Astals Cid:
> > > El dilluns, 25 d’abril de 2016, a les 10:59:13 CEST, Friedrich W. H.
> > > Kossebau
> > > 
> > > va escriure:
<snip>
> > > > So do any projects which are build on KDE CI need to have
> > > > ECMEnableSanitizers.cmake included?
> > > > 
> > > > Would it make sense to have ASan as an option to be turned off?
> > > 
> > > It's compile time, it's off for your project, but you're linking against
> > > KF5 libraries that have ASAN compiled in.
> > > 
> > > > And is that possible, or is ASan usage viral (if deps built on CI have
> > > > it,
> > > > it needs to be used)?
> > > 
> > > Yes ASan usage is viral-ish, if you're using a library that was compiled
> > > with ASAN you either need to compile your binary with asan too or pass
> > > the
> > > LD_PRELOAD as the error says, that may be tricky since it needs a full
> > > path.
> > 
> > Given we have stable setting on CI, the path might be known perhaps.
> > 
> > What needs to be done with LD_PRELOAD here exactly? Perhaps that could be
> > done optionally based on a flag in the build setup in the future.
> 
> You set it to the asan library before running your binary.

Okay, that sounds doable. "Just" needs someone to add support for that :)
Filed a feature request on phabricator for that, anyone interested to earn 
some laurels on that?
	https://phabricator.kde.org/T2366

> > Requiring ECMEnableSanitizers.cmake (or equivalent for non-cmake-based
> > buildsystem) for any projects on KDE CI to have tests being run properly
> > (if using other KDE CI products) feels like a small obstacle.
> > If possible without too much pain, it might be nice to avoid that.
> 
> It's hard to avoid unless you compile all libraries twice both with and
> without ASAN.

Double builds ideally can be avoided. And after all ASAN is very much useful 
on CI, that's why you(?) pushed it there, for some good catches already 
(myself could also harvest some bugs from it already) :)

> It is not a requirement for "any projects on KDE CI".
> 
> As pointed you can just LD_PRELOAD the ASAN library if you have troubles.
> Also that is only needed if you use other projects that are linked against
> ASAN.

As I understood it so far, almost anything built on KDE CI is built with ASAN, 
incl. 3rd-party dependencies like Qt5, no? As said above, it only makes sense 
to me to do it. But we need to also have support for the non-ECM-using 
projects, that's what I am here for and try to understand how things are done, 
to see what could be done.

> That is, you're trying not to use ECM (or ECMEnableSanitizers.cmake) but you
> depend on KF5 stuff that depends on ECM/ECMEnableSanitizers.cmake, maybe
> you're trying to be too fine in not needing ECM.

While I personally would also see to use ECM & CMake where possible, we still 
need to consider at least:

a) KF5 products do not require CMake as the buildsystem for any of its 
consumers. There is extra dance for supporting qmake/pkg-config buildsystems 
at least. So other potential KDE projects which use KF5 but not CMake cannot 
use ECM. Ideally there would be similar helpers like ECMEnableSanitizers.cmake 
one day for them, sure, but those still would be extra dependencies, and any 
extra dependency increases burdens, so would be nice to have it special 
settings for KDE CI optional if possible without a big deal.

b) Qt5 on CI is also build with ASAN (AFAIK, that is why the all Marble tests, 
which are Qt5-only, are failing, unless I missed something). So Qt5-only 
projects (as in: ECM/KF5-less) still would need to have separate support by/
for the KDE CI.

Cheers
Friedrich