[pgrouting-dev] Version, version, who has the version

[Stephen Woodbridge]

On 5/29/2013 1:51 AM, Daniel Kastl wrote:
>
>
>
> On Wed, May 29, 2013 at 2:33 PM, Dave Potts <dave.potts at pinan.co.uk
> <mailto:dave.potts at pinan.co.uk>> wrote:
>
>     On 29/05/13 06:20, Daniel Kastl wrote:
>
>     Looks great as long as it returns all the information required for
>     debugging pg route that can not be got from elsewhere.  It returns
>     information about which version of the pgr code has been used, but
>     does it include the version information for the dependency of
>     libraries used to build pgr?
>
>     For example if I use select postgis_version
>
>     I get 2.0 USE_GEOS=1 USE_PROJU=1 USE_STATS=1
>
>     postgis_full_version
>
>     POSTGIS="2.0.0 r9605" GEOS="3.3.8-CAPI-1.7.82 PROJ="Rel.4.8.0, 6
>     March 2012" GDAL="GDAL 1.9.2, release 2012/10/08" LIBJSON="UNKNOWN"
>     RASTER
>
>
> Hi Dave,
>
> With CMAKE we know about the versions of PostgreSQL, CGAL, Boost for
> example.
> I don't think we need to include PostgreSQL and PostGIS version as you
> can just query for it with the PostgreSQL and PostGIS functions.
> Except we think it's important to know with which version it was
> compiled. For example someone might just copy old pgRouting accidentally
> with a database dump and functions might have conflicts with PostGIS for
> example. But PostGIS doesn't do this either, right?
>
> Indeed we could think about to add the version of Boost and CGAL. There
> are no other dependencies at the moment.
> I changed the function to return a table, so it's quite easy to add a
> cgal and boost column actually.

Dave we are trying to move away from optional builds. So ultimately 
there will be not options and you will just build it. There have been 
issues with various Boost versions and compiling, but I have resolved 
most (all?) of these issues and once you compile we have not had any 
runtime issues able specific boost versions that I am aware of. CGAL 
will hopefully go away in the future but even if it doesn't, it is very 
stable and we have never had a version specific bug related to that.

So why does PostGIS do this? They work very closely with the development 
of GEOS, GDAL, and PROJ and in fact so closely that certain features in 
postgis are dependent on very recent versions of these libraries. It is 
essential that this information is report with a bug because often the 
same developers that are wrapping the functions into postgis are also 
developing the underlying library code also.

I'm not opposed to adding CGAL and Boost versions but I'm not sure of 
the value. @Daniel, I'm fine with adding these if you want.

>   @Steve
> To answer my own question:
>
>
>     How do you manage to get the updated VERSION file to be part of the
>     last commit?
>     I added the pre-commit file as you said, but every time I commit,
>     the VERSION file changes and is marked as modified. And on the
>     Github repository I'm theoretically always one commit hash behind.
>
>
> With "git commit -a" staged files that have been modified and deleted
> get included.
> I usually didn't use "-a", so need to be more careful now when doing a
> commit ;-)

Yes, but if you have added files use "git status" first to see what 
files might be new that need to be added.

-Steve

> Daniel
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.de <http://georepublic.de/>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>