<div dir="ltr"><span style="color:rgb(33,33,33);font-size:13px">Dear all</span><div><font color="#212121"><br></font></div><div><font color="#212121">I would like to discuss the way we want the sip files to be built in QGIS.</font></div><div><font color="#212121"><br></font></div><div><font color="#212121">Main things to know for those not familiar with recent changes:</font></div><div><font color="#212121">- 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.</font></div><div><font color="#212121">- 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.).</font></div><div><font color="#212121">- There are two configurations </font><span style="color:rgb(33,33,33)">running </span><span style="color:rgb(33,33,33)">on Travis in parallel:</span></div><div><font color="#212121">  * the main build for compilation and running the core and application test</font></div><div><font color="#212121">  * code_layout which takes care of running static tests (spelling, indentation, documentation, sipify)</font></div><div><br></div><div>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).</div><div><br></div><div>To achieves this, I<span style="color:rgb(33,33,33);font-size:13px"> 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.</span></div><div><div><br style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">Anyway I wonder if it’s really coherent to have:</span><br style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">* cmake creating the include files</span><br style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">* prepare-commit or manual trigger of a perl script to build the sip files</span></div><div><br></div><div><span style="font-size:13px;color:rgb(33,33,33)">The choices I see:</span></div><div><br style="font-size:13px;color:rgb(33,33,33)"><span style="font-size:13px;color:rgb(33,33,33)">1) scripts to create both the include and the sip files</span></div><div><span style="font-size:13px;color:rgb(33,33,33)">    - need to create a new test to check that all headers have sip files (would be run in code_layout config)</span></div><div><br style="font-size:13px;color:rgb(33,33,33)"><span style="font-size:13px;color:rgb(33,33,33)">2) cmake for the include + script for the sip files </span></div><div><span style="font-size:13px;color:rgb(33,33,33)">    - not really coherent to me</span></div><div>    - no need to add new test</div><div><br><span style="font-size:13px;color:rgb(33,33,33)">3) </span><span style="color:rgb(33,33,33);font-size:13px">cmake for the include + make (compile time) for the sip files </span></div><div><span style="color:rgb(33,33,33);font-size:13px">    - use CMake </span><font color="#212121">add_custom_command to add sipify</font><font color="#242729"> to the compile process</font></div><div><span style="font-size:13px;color:rgb(33,33,33)">    - this would require perl to build the project</span></div><div><font color="#212121">    - one would have to build before pushing (or run sipify manually)</font></div><div><span style="font-size:13px;color:rgb(33,33,33)">    - is it fine to push built files to source?</span></div><div><br><span style="font-size:13px;color:rgb(33,33,33)">4) cmake for both without sip in source </span></div><div>    - similar to above</div><div>    - is sipify stable enough? not sure.<br><br style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">None of these solutions is really complicate to implement. It’s more a matter of coherence and prevision.</span></div><div>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.<br style="color:rgb(33,33,33);font-size:13px"><br style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">What are your thoughts on this?</span><br style="color:rgb(33,33,33);font-size:13px"><br style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">Cheers,</span><br style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">Denis</span><br style="color:rgb(33,33,33);font-size:13px"><br style="color:rgb(33,33,33);font-size:13px"><div><br></div></div></div></div>