<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Dear Radostan Riedel,</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Lucida Sans'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Hope that's more clear now.<br></span></blockquote><br></div><div>Crystal clear! Thanks for the explanations.</div><div><br></div><div>Now going back to patch 0007-adding-shlib-versioning, is it correct that we would just need to do:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>env.Append(SHLINKFLAGS= [ "--version-info=c.r.a" ]</div><div> for the env that build a particular .so? Well, that would be for gcc and clang only of course. To be cross-platform I would suggest adding a pseudo-builder SetVersionInfo(vers) that does the right thing on Unix and nothing on Windows (for the time being, as perhaps there is a similar mechanism with msvc).</div><div><br></div><div>But your well-written patch and that little sugar are the easy part as they are of the write once, reuse forever nature. We need a workflow here and the two extremes would be as follow.</div><div><br></div><div>1. Each and every cctbx developer becomes aware of so-versioning. Let's say a module is at 2.3.4, so we have</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>env.SetVersionInfo(vers="2.3.4")</div><div>and then a change is made to the C++ code. The developer responsible for that change should then figure out the new c.r.a and then add a comment</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>env.SetVersionInfo(vers="2.3.4", #next release# vers="c.r.a")</div><div>It would then be easy to automate an edit en-masse before release that would change that line and all its sisters to</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>env.SetVersionInfo(vers="c.r.a")</div><div>That's basically a formalised version of your proposition in your answer to Johan earlier.</div><div><br></div><div>2. Cctbx developers would not care about so-versioning and before a Debian release, the cctbx Debian maintainers would go through each call to SetVersionInfo to set the right c.r.a, based on a careful examination of the commits, complemented by asking questions to the core cctbx developers (or simply open questions on this forum).</div><div><br></div><div>The reality is that it may end up in-between those extremes. The C++ code tends to be much more stable than the Python code. Thus the effort of working out the so-versioning changes is less daunting than it seems. </div><div><br></div><div>I am much more worried about Python if it comes to that:</div><div><br></div><div><blockquote type="cite">I don't think there is anything special about versioning python extensions. It<br>should be versioned by distutils like the module too. But maybe Baptiste knows more on that.<br></blockquote><br></div><div>There are relatively very few shlibs compared to Python modules. Keeping track of the version of all of the latter by hand would be an enormous amount of work. I don't think we can get it done cheaply with some automatic keyword expansion if we want proper major.minor.patch or worse something as involved as so-versioning.</div><div><br></div><div>Best wishes,</div><div><br></div><div>Luc</div><div><br></div><div><br></div><br></body></html>