<div dir="ltr"><div dir="ltr"><div>Hi all,</div><div><br></div></div><div><br></div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Am I the only QGIS dev highly frustrated by the bottleneck of sip-build <br>
when building QGIS? Can we do something (funding upstream?) to improve that?</blockquote><div><br></div><div><div>I used to be quite frustrated when sip4 support was dropped, as sip-build times were really terrible with sip 6 at the time.</div><div>After
 David's fixes in Oct/Nov 2025 though, things are back to normal. With 
sip-tools v6.15+ I don't think sip-build is a bottleneck any more for me.</div><div>I'm more annoyed that touching any enum or docstring in qgis.h will trigger an almost full rebuild of the whole project!</div><div>Though, I still often do `ninja qgis` during iterative rebuilds to avoid sip-build if not strictly necessary.</div><div><br> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- we bind to Python a very large part of our header files (more than <br>
half). I've always found that the amount of things exposed to Python was <br>
excessive. IMHO we should be much more conservative, and wait for plugin <br>
authors to ask for an API to be exposed, rather than expose it prematurely.<br></blockquote><div><br></div><div> My personal preference would be to expose as much as the stable API promise allows us to, then encourage development of new and often </div><div>niche features to be done as python plugins instead of having them in core.</div><div><br></div><div>Best,</div><div>Stefanos</div></div></div>