<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Denis,<br>
</p>
<div class="moz-cite-prefix">On 6/15/17 8:19 AM, Denis Rouzaud
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMtsY+YadiXv+BeWecq6Xs1y8Z+ZQnxXfr8gAKohuEextD2zMw@mail.gmail.com">
<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>
</div>
</blockquote>
Sounds like the logical next step while #4 is not yet an option.<br>
<blockquote type="cite"
cite="mid:CAMtsY+YadiXv+BeWecq6Xs1y8Z+ZQnxXfr8gAKohuEextD2zMw@mail.gmail.com">
<div dir="ltr">
<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>
</div>
</blockquote>
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.<br>
<blockquote type="cite"
cite="mid:CAMtsY+YadiXv+BeWecq6Xs1y8Z+ZQnxXfr8gAKohuEextD2zMw@mail.gmail.com">
<div dir="ltr">
<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>
</div>
</blockquote>
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?<br>
<blockquote type="cite"
cite="mid:CAMtsY+YadiXv+BeWecq6Xs1y8Z+ZQnxXfr8gAKohuEextD2zMw@mail.gmail.com">
<div dir="ltr">
<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>
</div>
</div>
</div>
</blockquote>
In the long run this is my preference, no doubt.<br>
<br>
But all in all, I think you've got the best overview and I fully
trust you to take a good decision.<br>
<br>
Cheers<br>
Matthias<br>
<blockquote type="cite"
cite="mid:CAMtsY+YadiXv+BeWecq6Xs1y8Z+ZQnxXfr8gAKohuEextD2zMw@mail.gmail.com">
<div dir="ltr">
<div>
<div><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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
QGIS-Developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<br>
</body>
</html>