I'm afraid your's truly might take a bit of the blame. The basis of the logic was likely my original Python code, which did just enough to make Ubuntu work.

In D7736#154948, @jasontibbitts wrote:

I hate to add a ping without any useful review, but I'm quite interested in this effort as I have a pykde4-based application which I would really like to get ported to the modern frameworks. Current distro packages of pykde4 are increasingly broken, and coverage of the existing bindings isn't sufficient to get the stuff I'm using (which isn't much, really) running.

Is there anything that someone like me can do to help with this?

My suggestion would be to focus any review efforts in this order:

My comments here are phrased as if this SIP-based approach was the solution eventually adopted (cppyy might be different). With that said...

I did some negative testing, and from what I can see, 3.8 might well be OK
for the ECM fork. My version depends on 3.9 (for example, there are some
new constants defined by clang which I use), but I've no idea if this will
ever be merged.

Fwiw, I think that a specific version check may not be needed. The original
code I wrote, which I assume Steve may have simply carried forward in the
cmake ecm logic, DID have a version check but only because the python
bindings were newish circa libclang 3.8.

I think the scope of the changes in this commit are perfectly reasonable. I don't think it is unreasonable to group them either.

The PEP-8 changes are some blank line changes.