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

[Daniel Kastl]

>  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.
>
>
I already added Boost, but I didn't add CGAL.
Boost was possible after finding the right hints in the CMake source file.
For CGAL I couldn't find variables for version information, so I just leave
it away. If someone wants to invest time in this, then please go ahead.
Otherwise I agree with Steve that CGAL is a) stable, b) optional and c)
hopefully not needed anymore some time in the future.

Daniel




-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20130529/5062fd05/attachment.html>