<div dir="ltr">Hi Nyall,<div><br></div><div>Thanks for the feedback.<br><br><div class="gmail_quote"><div dir="ltr">Le mer. 31 mai 2017 à 23:14, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 31 May 2017 at 22:15, Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>> wrote:<br>
> Dear all,<br>
><br>
> Our automatic SIP files generation is almost there and I would like to<br>
> remove the SIP coverage test from running on Travis.<br>
<br>
> Is this acceptable?<br>
<br>
In general, but...<br>
<br>
> Is there any reason to keep the test (running on Travis)?<br>
<br>
There's 2 extra things the sip coverage test does which the sipify test doesn't:<br>
<br>
1. Flags if a class is totally missing from the bindings. The sipify<br>
test can't detect when someone's added a new header to the project<br>
without adding a corresponding .sip include to the<br>
core/gui/server/analysis.sip files. Ideally this would be fixed with<br>
some cmake magic which avoids the need to even manually build the<br>
core.sip/gui.sip/etc files...<br></blockquote><div><br></div><div>So, we have 3 types of headers in core:</div><div>1) automatic SIP file creation</div><div>2) manual SIP file creation (might be not needed anymore at some point)</div><div>3) no SIP file creation</div><div><br></div><div>What I would propose is to use some macro definition in the header for case 2) and 3), like:</div><div>#define SIP_MANUALLY_CREATED</div><div>or</div><div>#define SIP_NOT_GENERATED</div><div><br></div><div>By default, the SIP file would be automatically created.</div><div><br></div><div>The core/gui/etc.sip could then automatically be generated either by CMake or by a script. </div><div><br></div><div>This would depend if we want to keep the SIP files in the source. I tend to think they're quite useful there for inspection and that the sipify script is (still?) too fragile to fully trust it.</div><div>If we keep them in source, does it make sense to use CMake to build the core.sip file? or a script run by prepare-commit.sh as it is now?</div><div><br></div><div>What do you think?</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Checks that the methods *are* actually accessible in the Python<br>
bindings. Occasionally there'll be weird things where even though a<br>
method is correctly listed in the .sip files, it just doesn't exist in<br>
the Python library. There's no pattern here - it happens differently<br>
on different platforms. But this is a sip bug, so I don't really care<br>
if we lose this extra check.<br>
<br>
For me 1 would need to be addressed before we can drop the test.<br>
<br>
Nyall<br>
</blockquote></div></div></div>