<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 28, 2013 at 10:00 PM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 5/28/2013 12:45 AM, Daniel Kastl wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
<br>
<br>
On Tue, May 28, 2013 at 1:16 PM, Stephen Woodbridge<br></div><div class="im">
<<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a> <mailto:<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.<u></u>com</a>>> wrote:<br>
<br>
I have made a bunch of changes that are all version related.<br>
<br>
1. I have added three functions (not documented)<br>
<br>
pgr_test=# select pgr_version();<br>
pgr_version<br>
-------------<br>
2.0.0-dev<br>
(1 row)<br>
<br>
pgr_test=# select pgr_full_version();<br>
pgr_full_version<br></div>
------------------------------<u></u>__----------------<div class="im"><br>
2.0.0-dev v2.0dev-271-g6eeef9b sew-devel-2_0<br>
(1 row)<br>
<br>
pgr_test=# select pgr_build_version();<br>
pgr_build_version<br></div>
------------------------------<u></u>__------<div><div class="h5"><br>
v2.0dev-271-g6eeef9b sew-devel-2_0<br>
(1 row)<br>
<br>
Here is what all this means:<br>
<br>
2.0.0-dev v2.0dev-271-g6eeef9b sew-devel-2_0<br>
--------- ------- --- ------- -------------<br>
VERSION TAG BUILD HASH BRANCH<br>
<br>
<br>
2. I have added a top-level file VERSION and tools/pre-commit hook<br>
to keep it updated. Daniel you will have to copy tools/pre-commit to<br>
.git/hooks/pre-commit<br>
<br>
I'm not sure how much I like this. I have tried a post-commit hook<br>
which updates the local file with the hash and build info after the<br>
commit in the local copy but not the copy send to github and the<br>
pre-commit hook updates the file with the has BEFORE the commit so<br>
it always reflects and state before the commit, but that also means<br>
the number in the file will match what is on the server.<br>
<br>
BTW, It is not possible to set the hash of a current commit into a<br>
file that is getting committed because the hash IS based on the<br>
content of the files committed, so you get infinite recursion!<br>
<br>
<br>
<br>
Hi Steve,<br>
<br>
The Git hooks look like a good way to automate this.<br>
I always thought to use CMake GIT module, but obviously this doesn't<br>
work if the source is not a repository.<br>
<br>
Looking at PostGIS they also include information about libraries<br>
required to build and compile.<br>
So I thought we could somehow also add information about the version of<br>
CMake and Boost for example.<br>
But I don't know exactly how to put this information in SQL files ...<br>
probably the Sphinx CMake module does something like this, but I need to<br>
study this first.<br>
</div></div></blockquote>
<br>
OK, I do not think that we need to add the library information. In the postGIS case, there code and therefore their bugs, are highly related to their libraries and they also develop, support and release some of the libraries. The only library that we are dependent on at the moment is CGAL and I don't expect that we will have many bugs because of this dependency. So lets not do this.<br>
<br>
Regarding how the names get into the pgr_*version() functions the SQL just have cmake variable names and in CMakeLists.txt we have:<br>
<br>
configure_file("${CMAKE_<u></u>BINARY_DIR}/lib/pgrouting--${<u></u>PGROUTING_VERSION_STRING}.<a href="http://sql.in" target="_blank">sql.<u></u>in</a>"<br>
"${CMAKE_BINARY_DIR}/lib/<u></u>pgrouting--${PGROUTING_<u></u>VERSION_STRING}.sql")<br>
<br>
that does the subsitution. You can do the same thing with doc files if you have cmake pre-process them, do it how you are doing it now.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
I think the version function is't something that may not change in<br>
future versions. So we could leave it like this and we can improve it<br>
when we have a good idea.<br>
<br>
Just one thing I never understood also with the PostGIS version function:<br>
<br></div>
* What's the purpose of multiple functions?<br>
* Why does the return type needs to be a single text string and can't<div class="im"><br>
be split into multiple attributes instead?<br>
</div></blockquote>
<br>
It is just easier to use the function that you gives you what you need rather than require the user to figure out how to parse the strings. We already know how to do that, but everyone might not.<div class="im"><br></div>
</blockquote><div><br></div><div style>Hi Steve,</div><div style><br></div><div style>What about just one "pgr_version()" function?</div><div style>I don't get the use case where we need two of them ;-)</div>
<div style><br></div><div style>I think "pgr_version()" should then return the "full" version.</div><div style><br></div><div style>Daniel</div><div style><br></div><div><br></div><div><br></div><div>
<br>
</div><div><br></div><div> </div></div>-- <br><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66,99,171)" target="_blank">daniel.kastl@georepublic.de</a><br>
Web: <a href="http://georepublic.de/" style="color:rgb(66,99,171)" target="_blank">http://georepublic.de</a></span>
</div></div>