D22790: Add option to build Qt Designer plugin (BUILD_DESIGNERPLUGIN, default ON

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> apol wrote in CMakeLists.txt:29
> Would it make sense to have this option with the macro? This way we make sure it's easy to disable and we save some boilerplate on every project.

Yes, asked myself the same when doing all the patches for all the KF modules :)
My answer to this has been:
this might be too aggressive to non-KF projects which might want to use these macros, but with other option name, other default setting or even unconditionally.

It rather points out another problem: there is right now massive cmake code duplication in all the KDE Frameworks modules.
IMHO it would make more sense to invest into some ECMKFSetup & Co. macro set for de-duplicating all the repeated explicit logic across all the modules, also to keep & improve consistency between all the modules.

I know this from other projects where it's successfully done, e.g. in Okteta for each of the currently 6 libs then to setup all the header installation, cmake/pkconfig/pri file generation code is as simple as:

  okteta_add_library(Gui NAMESPACE Okteta
      PUBLIC
          OktetaCore
          Qt5::Widgets
      PRIVATE
          KF5::I18n
          KF5::ConfigWidgets
      VERSION     ${OKTETAGUI_VERSION}
      SOVERSION   ${OKTETAGUI_SO_VERSION}
      ABIVERSION  ${OKTETALIBS_ABI_VERSION}
      SOURCES   ${oktetagui_LIB_SRCS}
      HEADERS   ${oktetagui_LIB_HDRS}
      CCHEADERS ${oktetagui_LIB_CCHDRS}
      NO_TARGET_NAMESPACE
      NO_VERSIONED_INCLUDEDIR
      NO_VERSIONED_PACKAGE_NAME
  )
  
  okteta_add_cmakeconfig(Gui NAMESPACE Okteta)
  
  okteta_add_qmakeconfig(Gui NAMESPACE Okteta
      DEPS OktetaCore widgets
  )
  
  okteta_add_pkgconfig(Gui NAMESPACE Okteta
      DEPS OktetaCore Qt5Widgets
      DESCRIPTION "Okteta Gui"
  )

And any improvements not needing new input data/arguments can be done centrally in the macro implementation, those which are just need visiting of all places to add any new arguments.

Never proposed this so far, fearing the rather big work to implement that will get on my desk :P But very much think such KF-specific generic convenience macros would improve things for KDE Frameworks.

REPOSITORY
  R302 KIconThemes

REVISION DETAIL
  https://phabricator.kde.org/D22790

To: kossebau, #frameworks
Cc: apol, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190729/8fd4c10b/attachment-0001.html>