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 <[email protected] > <mailto:[email protected]>> a Γ©crit : > > On 31 May 2017 at 22:15, Denis Rouzaud <[email protected] > <mailto:[email protected]>> 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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
