<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br>Partial response, no time for more now.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 August 2015 at 12:15, Friedrich W. H. Kossebau <span dir="ltr"><<a href="mailto:kossebau@kde.org" target="_blank">kossebau@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Am Montag, 31. August 2015, 02:29:29 schrieb Jaroslaw Staniek:<br></div></div><span>
> >> For people building largely by hand, I'd introduce a support for<br>
> >> specific case: a<br>
> >> find_package wrapper that checks if the dependency has an exact git<br>
> >> revision. That's like an assertion that tells you that your deps are<br>
> >> too old (or too new, or even from incompatible branch - use git to<br>
> >> find out). (I already offer the git revision information for kdb.git,<br>
> >> etc. and believe providing it even in --help for apps is a good thing<br>
> >> in modern times).<br>
> ><br>
> > Tagging a certain devel state with the main development branch sounds like<br>
> > an interesting solution. Just, how would that be integrated in people's<br>
> > workflow? How does the git revision info get from e.g. Calligra's<br>
> > CMakeLists.txt into the commands that fetch stuff from those separate<br>
> > repos, and then also make sure the certain version is checked out, build<br>
> > and installed?<br>
><br>
> When we build we have set up a list of dirs: builddir, source dir and<br>
> prefix dir.<br>
> So while building, the sourcedir is known and build-dependency<br>
> checking can look into the sourcedir to know the required versions.<br>
> (Actually similar tool could update the cmake file for me when I as a<br>
> developer want to bump up the dependent versions; that's not needed<br>
> for every commit though)<br>
<br>
</span>Under the line, that sounds like a complicated system to me, with the need for<br>
utils which are yet to be written.<br>
More, it will only work for those who adapt to that system. What about 3rd-<br>
party apps that want to develop again master branch of kdb? But use qmake? Or<br>
some other custom build system?<br>
<br>
What about using KProperty and KReport as testing ground for now for the<br>
approach you are proposing?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​+1 or look below<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> > Also having to adapt the revision info any time one works on the external<br>
> > repos (with changing commit ids) smells like a lot of painful work, not<br>
> > only because due to waiting for cmake to finish reconfiguring :/<br>
> ><br>
> > So, interesting idea, but needs proof it stays the daily workflow for me<br>
> > :)<br>
><br>
> The idea addresses a case that may or may not be a corner case,<br>
> depends on developer.<br>
<br>
</span>For the start, for now, in current Calligra master I would like to propose to<br>
apply the BIC-day approach.<br>
<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I am all for known workflows that cause no stress or wtf moments.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I understand developers want to be sure they have the "current" code.<br><br>​<div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​The BIC days can work, the change from the above proposal would be then: use a year+week number or so instead of git revision or cross-repo tag name. The year+week number is a cross-repo too of course. It can be checked at cmake level that during development branch we have too old deps such as kreport/kdb/etc.<br></div><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">It's also all about one more thing. Even given that API/ABI is carefully maintained, behaviour can change or fixes can appear in dependencies such as kreport.git. Sometimes a bug in Kexi gets in fact fixed by kreport.git commits only.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">One thing is that if for tag 201540 (2015, Week 40) there were no commits for kreport, we would need to add a tag anyway. Not an overhead I guess? In 2 years we'd end up with about 100 tags, that's all :)<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So a Stage&Flake-concentrated developer only has to pull kdb, kproperty &<br>
kreport on one day in the week, to always stay with a building master.<br>
<br>
Once there is a working alternative, which is understood and has working<br>
utils, we can switch to that any time.<br></blockquote><div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Yue, Camilla, Leinir, Zagge, Tomas, what is your take on this?<br>
<div><div><br>
Cheers<br>
Friedrich<br>
_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org" target="_blank">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div>regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>