D7736: Not-to-be-merged review of Python bindings generator

[Shaheed Haque]

shaheed added a comment.


  My comments here are phrased as if this SIP-based approach was the solution eventually adopted (cppyy might be different). With that said...
  
  This...
  
  > (this thing is huge).
  
  and this...
  
  > One question: would it be possible to have the bindings per-framework, rather than a single, long list? This is also what made PyKDE4 unwieldy. IOW, each Framework should ship their (optional) bindings.
  
  are related. Though the diff is huge, much of that is due to the 98 files in the PyKF5 directory (as opposed to the 10 that actually contain the crown jewels, plus the 5 template-related files). Let me explain...
  
  Those 98 files are effectively two things:
  
  1. The basis of the regression test suite for the tooling. In this sense, these rules (more or less) do just enough work to get beyond the fail-on-first-error semantics of the SIP compiler, and so are needed to allow enough of the syntax of the KF5 suite in the long list to be processed for me to feel comfortable that the tooling is "complete".
  2. The starting point for the real per-framework rules that would be used in real life. In real life, I would expect the bindings to be packaged per-framework via ECM as you say, with each framework owner starting from the set of rules here.
  
  > We can put the tooling in ECM so that everything is in place for all the Frameworks. (This is how the current approach works):
  
  The tooling in ECM would likely also host the shared rules (including the 5 files worth of template support) much as the current ECM does.

REPOSITORY
  R240 Extra CMake Modules

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

To: shaheed, lbeltrame
Cc: #frameworks, #build_system
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20170908/ee01460c/attachment.html>