[QGIS-Developer] SIP coverage test removal and Travis optimization

[Matthias Kuhn 🌍]

Hi Denis

On 06/02/2017 11:17 AM, Denis Rouzaud wrote:
> Hi Nyall,
> 
> Thanks for the feedback.
> 
> Le mer. 31 mai 2017 à 23:14, Nyall Dawson <nyall.dawson at gmail.com
> <mailto:nyall.dawson at gmail.com>> a écrit :
> 
>     On 31 May 2017 at 22:15, Denis Rouzaud <denis.rouzaud at gmail.com
>     <mailto:denis.rouzaud at gmail.com>> wrote:
>     > Dear all,
>     >
>     > Our automatic SIP files generation is almost there and I would like to
>     > remove the SIP coverage test from running on Travis.
> 
>     > Is this acceptable?
> 
>     In general, but...
> 
>     > Is there any reason to keep the test (running on Travis)?
> 
>     There's 2 extra things the sip coverage test does which the sipify
>     test doesn't:
> 
>     1. Flags if a class is totally missing from the bindings. The sipify
>     test can't detect when someone's added a new header to the project
>     without adding a corresponding .sip include to the
>     core/gui/server/analysis.sip files. Ideally this would be fixed with
>     some cmake magic which avoids the need to even manually build the
>     core.sip/gui.sip/etc files...
> 
> 
> So, we have 3 types of headers in core:
> 1) automatic SIP file creation
> 2) manual SIP file creation (might be not needed anymore at some point)
> 3) no SIP file creation

How do you intend to handle additional files like `conversion.sip`?

Something like this?

core.sip.template:

...
%Include conversion.sip
[auto_generated_files] // Some kind of placeholder
...

Matthias

> 
> What I would propose is to use some macro definition in the header for
> case 2) and 3), like:
> #define SIP_MANUALLY_CREATED
> or
> #define SIP_NOT_GENERATED
> 
> By default, the SIP file would be automatically created.
> 
> The core/gui/etc.sip could then automatically be generated either by
> CMake or by a script. 
> 
> 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.
> 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?
> 
> What do you think?
> 
> 
>  
> 
> 
>     2. Checks that the methods *are* actually accessible in the Python
>     bindings. Occasionally there'll be weird things where even though a
>     method is correctly listed in the .sip files, it just doesn't exist in
>     the Python library. There's no pattern here - it happens differently
>     on different platforms. But this is a sip bug, so I don't really care
>     if we lose this extra check.
> 
>     For me 1 would need to be addressed before we can drop the test.
> 
>     Nyall
> 
> 
> 
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>