[QGIS-Developer] Let (C)Make run sipify?

[Matthias Kuhn]

Hi Denis,

On 6/15/17 8:19 AM, Denis Rouzaud wrote:
> Dear all
>
> I would like to discuss the way we want the sip files to be built in QGIS.
>
> Main things to know for those not familiar with recent changes:
> - A perl scrit takes care of updating the sip files. It is either run
> manually (sipdiff or sipify_all.sh) or automatically
> (prepare-commit.sh). A test (qgis_sip_uptodate) takes care of
> controlling that files are up to date in the source.
> - The file saying which file has to be sipified is updated manually
> (auto_sip.blacklist). If one adds a new header, he has to add the sip
> files to corresponding include file (core.sip,gui.sip, etc.).
> - There are two configurations running on Travis in parallel:
>   * the main build for compilation and running the core and
> application test
>   * code_layout which takes care of running static tests (spelling,
> indentation, documentation, sipify)
>
> The sip coverage test is still running on the main build because it
> requires the python bindings. To remove it (and save some time on
> Travis), the missing bit in code_layout configuration is checking that
> a new header got his sip file too (or was explicitly marked as non
> being exposed to the python bindings).
>
> To achieves this, I was thinking at letting cmake create the include
> sip file lists (core.sip, gui.sip, …) to get a compile error whenever
> someone adds a cpp header without its corresponding sip file. I gave
> it a try and it works well.
>
> Anyway I wonder if it’s really coherent to have:
> * cmake creating the include files
> * prepare-commit or manual trigger of a perl script to build the sip files
>
> The choices I see:
>
> 1) scripts to create both the include and the sip files
>     - need to create a new test to check that all headers have sip
> files (would be run in code_layout config)
Sounds like the logical next step while #4 is not yet an option.
>
> 2) cmake for the include + script for the sip files 
>     - not really coherent to me
>     - no need to add new test
I don't like this option too much, mostly because (if I understand
correctly) recreation of these files is triggered by a) build and b)
manual command or prepare-commit.sh. This seems a bit confusing to me.
>
> 3) cmake for the include + make (compile time) for the sip files 
>     - use CMake add_custom_command to add sipify to the compile process
>     - this would require perl to build the project
>     - one would have to build before pushing (or run sipify manually)
>     - is it fine to push built files to source?
One advantage of the current solution (w.r.t to sipify stability) is the
possibility to quickly edit the sip file without running sipify and
check if it fixes an issue (which can then lead to improvements in the
header or sipify.pl). I wonder if this workflow would still work with
this proposed approach?
>
> 4) cmake for both without sip in source 
>     - similar to above
>     - is sipify stable enough? not sure.
In the long run this is my preference, no doubt.

But all in all, I think you've got the best overview and I fully trust
you to take a good decision.

Cheers
Matthias
>
> None of these solutions is really complicate to implement. It’s more a
> matter of coherence and prevision.
> I would tend to go for 3 (and 4 in a later step). My main reason to
> this is to avoid relying on standalone scripts to build QGIS.
>
> What are your thoughts on this?
>
> Cheers,
> Denis
>
>
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170615/632b88d5/attachment.html>