* new branch sew-devel-2_0
* moved files into a new tree structure
* merged trsp into this structure
* checkin and pushed
* started working on getting just this much to build
* making changes to cmake stuff and debugging locally
* will push these changes soon
I also make some minor comments on the 2.0 dev wiki page. I'll update this once things settle down a little:
I found one thing I don't like about this structure and that is there are more little sql files to deal with, but my hope is that these can all be hidden as part of the CREATE EXTENSION command when I get to that.
My plan is something like this:
* get current tree to compile on old debian with pg8.3 and postgis 1.5.x
* I need to find/setup a system with pg9.1+ and postgis 2.0.x
* get it to compile there
* get the extension packaging to work
* get it working with windows
* then start renaming procedures and clean all that up (this might need to be done sooner rather than later).
I found one thing I don’t like about this structure and that is there are more little sql files to deal with, but my hope is that these can all be hidden as part of the CREATE EXTENSION command when I get to that.
Hi Steve,
CREATE EXTENSION is probably the most user-friendly way, so whether you have one SQL file or many, for the user it’S a single command.
Another possibility would be to concatenate SQL files as part of the build process.
For versions of PostgreSQL where CREATE EXTENSION isn’t available yet, a template database would be convenient. So a simple script or page in the documentation would be enough in that case.
Thoughts?
How about the library binaries. This would be then also one file per algorithm, right?
Could this be merged into a few as well?
I found one thing I don’t like about this structure and that is there are more little sql files to deal with, but my hope is that these can all be hidden as part of the CREATE EXTENSION command when I get to that.
Hi Steve,
CREATE EXTENSION is probably the most user-friendly way, so whether you have one SQL file or many, for the user it’S a single command.
Another possibility would be to concatenate SQL files as part of the build process.
For versions of PostgreSQL where CREATE EXTENSION isn’t available yet, a template database would be convenient. So a simple script or page in the documentation would be enough in that case.
Thoughts?
How about the library binaries. This would be then also one file per algorithm, right?
Could this be merged into a few as well?
Steve, I forgot to mention this:
Should we select a different “default” install directory?
I don’t know about Windows, but on Linux, /usr/share/postlbs (or later /usr/share/pgrouting) was the default destination.
PostGIS puts it’S SQL files into PostgreSQL contrib, and isn’t it necessary to do so if you want to support CREATE EXTENSION?
I’m somehow in favor of PostgreSQL contrib directory.
Today, I got cmake changes made so it now builds and compiles using the new tree structure. This required upgrading to cmake 2.8. I have not tried to install it in postgresql yet. These changes have been pushed to github.
I also have been looking at cmake to figure out how to intall all then build pieces as a postgresql extension and think I have most of that figured out.
More to follow as it gets done,
-Steve
On 3/5/2013 4:39 PM, Stephen Woodbridge wrote:
Hi All,
Just a quick update.
* new branch sew-devel-2_0
* moved files into a new tree structure
* merged trsp into this structure
* checkin and pushed
* started working on getting just this much to build
* making changes to cmake stuff and debugging locally
* will push these changes soon
I also make some minor comments on the 2.0 dev wiki page. I'll update
this once things settle down a little:
I found one thing I don't like about this structure and that is there
are more little sql files to deal with, but my hope is that these can
all be hidden as part of the CREATE EXTENSION command when I get to that.
My plan is something like this:
* get current tree to compile on old debian with pg8.3 and postgis 1.5.x
* I need to find/setup a system with pg9.1+ and postgis 2.0.x
* get it to compile there
* get the extension packaging to work
* get it working with windows
* then start renaming procedures and clean all that up (this might need
to be done sooner rather than later).
Today, I got cmake changes made so it now builds and compiles using the new tree structure. This required upgrading to cmake 2.8. I have not tried to install it in postgresql yet. These changes have been pushed to github.
Hi Steve,
I think to make cmake 2.8 a requirement is totally OK.
It’s already part of the previous Ubunut LTS release and probably all the other still supported distributions: http://packages.ubuntu.com/lucid/cmake
On Thu, Mar 7, 2013 at 1:57 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:
Hi All,
Today, I got cmake changes made so it now builds and compiles using
the new tree structure. This required upgrading to cmake 2.8. I have
not tried to install it in postgresql yet. These changes have been
pushed to github.
Hi Steve,
I think to make cmake 2.8 a requirement is totally OK.
It's already part of the previous Ubunut LTS release and probably all
the other still supported distributions: http://packages.ubuntu.com/lucid/cmake
OK, that is great. I'm happy with the progress so far and I hope to make good progress on getting cmake to pull everything into an extension. Once that happens, can turn my focus the actual code.
I also noticed that the CMake site as a CTest package. I have not looked at it but I'm wondering if it might not be good for building our test infrastructure with. Have anyone looked at this?
While it is important that we do something with respect to testing, I do not want to jump in without looking into what postgis and mapserver projects are already doing.
OK, that is great. I’m happy with the progress so far and I hope to make good progress on getting cmake to pull everything into an extension. Once that happens, can turn my focus the actual code.
I also noticed that the CMake site as a CTest package. I have not looked at it but I’m wondering if it might not be good for building our test infrastructure with. Have anyone looked at this?
While it is important that we do something with respect to testing, I do not want to jump in without looking into what postgis and mapserver projects are already doing.
I think it’s good to look what related projects do. And maybe they can tell, why they choose this tool and not another one.
Or maybe they can say if they are happy with their decision.
Once I looked for some extensions I found pgTAP, which could be also interesting: http://pgtap.org/
I have no preference so far. With past decisions it was usually good to look at what other OSGeo projects do.
Is there any chance of including a 'test' database with this release?
It could be used as a example to show that you have installed pg routing correctly, it would also ensure known set of test cases exists from every different method of generatinga route.
Dave.
OK, that is great. I'm happy with the progress so far and I hope
to make good progress on getting cmake to pull everything into an
extension. Once that happens, can turn my focus the actual code.
I also noticed that the CMake site as a CTest package. I have not
looked at it but I'm wondering if it might not be good for
building our test infrastructure with. Have anyone looked at this?
While it is important that we do something with respect to
testing, I do not want to jump in without looking into what
postgis and mapserver projects are already doing.
I think it's good to look what related projects do. And maybe they can tell, why they choose this tool and not another one.
Or maybe they can say if they are happy with their decision.
Once I looked for some extensions I found pgTAP, which could be also interesting: http://pgtap.org/
I have no preference so far. With past decisions it was usually good to look at what other OSGeo projects do.
Daniel
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>
Maybe Contributions would be welcome. Seriously if people want to contribute building test cases is a great way. Let me know and we can discuss the basic requirements. We could probably build a test database that has:
1. raw edge table
2. a table of queries to run on that table
3. a collection of stored procedures that validate query results
The idea be that we can run one query like:
select * from run_tests();
Test 1 - OK
Test 2 - Failed
Test 3 - OK
...
Or something along these lines. Automation can come later, if we have the database and the test queries.
I have thought about testing in the past an looked into some schemes for building automated tests but non that I have been happy with.
Testing has three major dimensions in my mind:
1. a test infrastructure for automating tests
2. unit tests that focus on the C/C++ algorithm code outside the DB
3. integration testing in the database
That said, I need to get the src tree reorganized and building and installing first.
-Steve
On 3/7/2013 11:05 AM, Dave Potts wrote:
On 07/03/13 06:40, Daniel Kastl wrote:
Hi
Is there any chance of including a 'test' database with this release?
It could be used as a example to show that you have installed pg routing
correctly, it would also ensure known set of test cases exists from
every different method of generatinga route.
Dave.
OK, that is great. I'm happy with the progress so far and I hope
to make good progress on getting cmake to pull everything into an
extension. Once that happens, can turn my focus the actual code.
I also noticed that the CMake site as a CTest package. I have not
looked at it but I'm wondering if it might not be good for
building our test infrastructure with. Have anyone looked at this?
While it is important that we do something with respect to
testing, I do not want to jump in without looking into what
postgis and mapserver projects are already doing.
I think it's good to look what related projects do. And maybe they can
tell, why they choose this tool and not another one.
Or maybe they can say if they are happy with their decision.
Once I looked for some extensions I found pgTAP, which could be also
interesting: http://pgtap.org/
I have no preference so far. With past decisions it was usually good
to look at what other OSGeo projects do.
Daniel
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>
A test dataset would be very much welcome!
If you have a good idea how to make a test data that is not too large but still allows to cover various use cases, that’s great.
Is there any chance of including a ‘test’ database with this release?
It could be used as a example to show that you have installed pg routing correctly, it would also ensure known set of test cases exists from every different method of generatinga route.
Dave.
OK, that is great. I’m happy with the progress so far and I hope to make good progress on getting cmake to pull everything into an extension. Once that happens, can turn my focus the actual code.
I also noticed that the CMake site as a CTest package. I have not looked at it but I’m wondering if it might not be good for building our test infrastructure with. Have anyone looked at this?
While it is important that we do something with respect to testing, I do not want to jump in without looking into what postgis and mapserver projects are already doing.
I think it’s good to look what related projects do. And maybe they can tell, why they choose this tool and not another one.
Or maybe they can say if they are happy with their decision.
Once I looked for some extensions I found pgTAP, which could be also interesting: http://pgtap.org/
I have no preference so far. With past decisions it was usually good to look at what other OSGeo projects do.
Contributions would be welcome. Seriously if people want to contribute building test cases is a great way. Let me know and we can discuss the basic requirements. We could probably build a test database that has: