Numerous build regressions

[Friedrich W. H. Kossebau]

Am Sonntag, 25. April 2021, 15:36:37 CEST schrieb Friedrich W. H. Kossebau:
> Am Sonntag, 25. April 2021, 14:18:29 CEST schrieb Friedrich W. H. Kossebau:
> > Am Sonntag, 25. April 2021, 09:56:17 CEST schrieb Ben Cooksley:
> > > These failures appear to be due to changes to the export header
> > > templates
> > > in extra-cmake-modules, and some SSL related functions in KIO.
> > 
> > Looking into the export header related one. Seems that bluez-qt includes
> > the export header also from C code, and the C preprocessor of clang (?)
> > on FreeBSD seems to handle a directive like
> > 
> >     #if defined(__has_cpp_attribute) && __has_cpp_attribute(deprecated)
> > 
> > not as one like myself would expect it, stopping evaluation before the &&
> > ?
> > 
> > 08:25:02  /usr/home/jenkins/workspace/Administration/Dependency Build
> > Extragear kf5-qt5 FreeBSDQt5.15/bluez-qt/build/src/bluezqt_export.h:42:37:
> > error: function-like macro '__has_cpp_attribute' is not defined
> > 08:25:02  #if defined(__has_cpp_attribute) &&
> > __has_cpp_attribute(deprecated)
> > 
> > Guess that needs some #ifdef __cplusplus protection of some kind. Anyone
> > experience with that, while I am learning while writing such code now?
> 
> Or rather that GCC has __has_cpp_attribute defined also in C mode, other
> than Clang, and there is no lazy evaluation by the preprocessor?
> 
> Still need to research in full detail, but have a first hot-fix testing
> right now locally that does some handling of inclusion of the generated
> export header in C mode, and would push later.
> 
> No clue yet whether the other KIO-related build failures also are related to
> the new export header changes, still need to look at that.

Turned out the KIO-related build failure was also caused by the change in the 
export header generation, which as a result started to have export/visibility 
macros evaluate to compiler-specific attribute markup (say, __attribute__) and 
deprecation attributes to standard ones ([[]]), which at least GCC seems to 
not like when being used together on the same class or function.

See also
https://bugs.kde.org/show_bug.cgi?id=436155

A fix based on the current understanding of the uncovered challenges has been 
pushed now to ECM, and rebuilds are triggered, hopefully they will work out. 
Thanks to (the people maintaining) CI for catching these builds-for-me non-
obvious issues quickly :)

Cheers
Friedrich