Hi
> On 2 Jun 2017, at 11:48, Matthias Kuhn ๐ŸŒ <[email protected]> wrote:
> 
> 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]>
>> <mailto:[email protected] <mailto:[email protected]>>> a รฉcrit :
>> 
>>    On 31 May 2017 at 22:15, Denis Rouzaud <[email protected] 
>> <mailto:[email protected]>
>>    <mailto:[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
> โ€ฆ


Or something like 
%Include auto_generated_files.sip
with a file with all of them.

Anyway, something like this, yes.

Would you prefer the CMake or the script approach?
I find it weird that CMake would output files which would be written in the 
source, so I would vote for the script.


> 
> 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] <mailto:[email protected]>
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>> 
> _______________________________________________
> QGIS-Developer mailing list
> [email protected] <mailto:[email protected]>
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> <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

Reply via email to