[pgrouting-dev] pgRouting 2.0 Update

pgRouting pgrouting-dev
1

Hi all,

I'm making some progress with pgRouting on Win64. I have been able to get my source tree to compile which means I have worked through the various issues of installing the various dependencies to pgRouting. There are still a few minor issues in this regard and Sanak is looking into one related to installing boost.

My source tree is not complete yet from the point of view that it still needs changes for:

1. creating all the postgresql extension files and installing them properly
2. for up grading the SQL to work with postgis 2.0+
3. testing the installed code
4. getting everything to work with 32 bit builds

But getting the dependencies to install and getting the source to compile on MinGW64 is a huge step. I have also brought the source back to Linux and made a few changes there. So a lot of back and forth to keep everything working on both sides.

Thanks,
   -Steve

2

Thanks, Steve!
The progress is encouraging.

I think it’s important that the basic structure is there, so that later old and new functionality can be added back easily by anyone, who wants to help. And that it’s clearly defined, what needs to be included with each new algorithm, such as directory structure, tests, documentation, etc…

Daniel

On Wed, Mar 13, 2013 at 12:13 PM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Hi all,

I’m making some progress with pgRouting on Win64. I have been able to get my source tree to compile which means I have worked through the various issues of installing the various dependencies to pgRouting. There are still a few minor issues in this regard and Sanak is looking into one related to installing boost.

My source tree is not complete yet from the point of view that it still needs changes for:

  1. creating all the postgresql extension files and installing them properly
  2. for up grading the SQL to work with postgis 2.0+
  3. testing the installed code
  4. getting everything to work with 32 bit builds

But getting the dependencies to install and getting the source to compile on MinGW64 is a huge step. I have also brought the source back to Linux and made a few changes there. So a lot of back and forth to keep everything working on both sides.

Thanks,
-Steve

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

3

On 3/12/2013 11:38 PM, Daniel Kastl wrote:

Thanks, Steve!
The progress is encouraging.

I think it's important that the basic structure is there, so that later
old and new functionality can be added back easily by anyone, who wants
to help. And that it's clearly defined, what needs to be included with
each new algorithm, such as directory structure, tests, documentation,
etc..

Exactly my goal. So the current tree has dijkstra, astar, shooting_star and trsp all in a core library but each in a separate src tree and because of additional dependencies, tsp and dd are in separate libraries but along side the others in the same tree structure.

Right now it is all getting sorted out in the cmake files. Eventually I will probably need to refactor the cmake files, but they are ok for now.

Basically each algorithm is in a tree like:

core/<algorithm>/
    doc/
    sql/
    src/
    test/

Currently, only sql and src are populated, but the basic structure is important as we move forward. Adding a new algorithm is just a matter of creating the tree and adding various CMakeFiles.txt files in each level of the tree and these can basically just mirror any of the parallel branches in the tree. When we start adding doc and tests I'll have to do some more work on the cmake files, but that can wait till I actually can install and test something.

-Steve

Daniel

On Wed, Mar 13, 2013 at 12:13 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

    Hi all,

    I'm making some progress with pgRouting on Win64. I have been able
    to get my source tree to compile which means I have worked through
    the various issues of installing the various dependencies to
    pgRouting. There are still a few minor issues in this regard and
    Sanak is looking into one related to installing boost.

    My source tree is not complete yet from the point of view that it
    still needs changes for:

    1. creating all the postgresql extension files and installing them
    properly
    2. for up grading the SQL to work with postgis 2.0+
    3. testing the installed code
    4. getting everything to work with 32 bit builds

    But getting the dependencies to install and getting the source to
    compile on MinGW64 is a huge step. I have also brought the source
    back to Linux and made a few changes there. So a lot of back and
    forth to keep everything working on both sides.

    Thanks,
       -Steve
    _________________________________________________
    pgrouting-dev mailing list
    pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
    <http://lists.osgeo.org/mailman/listinfo/pgrouting-dev&gt;

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/&gt;

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

4

Currently, only sql and src are populated, but the basic structure is important as we move forward. Adding a new algorithm is just a matter of creating the tree and adding various CMakeFiles.txt files in each level of the tree and these can basically just mirror any of the parallel branches in the tree. When we start adding doc and tests I’ll have to do some more work on the cmake files, but that can wait till I actually can install and test something.

Before you think about the “doc” let me know, because I already have something in mind.
I want to automatically build it with Sphinx so the website will be updated automatically.
The typical problem with documentation are different versions. But maybe that’S solved anyway if we keep it in the source tree.
Well, this can wait for April, I think.

Daniel

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

5

Hi Stephen,
is the branch supposed to be buildable on linux ?

I've been trying w/out success two days ago, while I filed a couple
of pull requests to be able to build the "master" branch on Ubuntu 12.04
(hint: waiting for merge :slight_smile:

Should I file tickets for build errors in the 2.0 branch ?
Which branch name, exactly ?

Thanks in advance

--strk;

http://www.cartodb.com - Map, analyze and build applications with your data

                                       ~~ http://strk.keybit.net

On Tue, Mar 12, 2013 at 11:13:05PM -0400, Stephen Woodbridge wrote:

Hi all,

I'm making some progress with pgRouting on Win64. I have been able
to get my source tree to compile which means I have worked through
the various issues of installing the various dependencies to
pgRouting. There are still a few minor issues in this regard and
Sanak is looking into one related to installing boost.

My source tree is not complete yet from the point of view that it
still needs changes for:

1. creating all the postgresql extension files and installing them properly
2. for up grading the SQL to work with postgis 2.0+
3. testing the installed code
4. getting everything to work with 32 bit builds

But getting the dependencies to install and getting the source to
compile on MinGW64 is a huge step. I have also brought the source
back to Linux and made a few changes there. So a lot of back and
forth to keep everything working on both sides.

Thanks,
  -Steve

6

On 13/03/13 04:09, Stephen Woodbridge wrote:
Hi Daniel,

Will you be including any of the other routing code with the 2.0 release as part of the core offering?

My KSP stuff follows the same template, with exception of the documentation which is a single read me file.

Are you going to build 32/64 version for Windows as well as Linux?

Dave.

On 3/12/2013 11:38 PM, Daniel Kastl wrote:

Thanks, Steve!
The progress is encouraging.

I think it's important that the basic structure is there, so that later
old and new functionality can be added back easily by anyone, who wants
to help. And that it's clearly defined, what needs to be included with
each new algorithm, such as directory structure, tests, documentation,
etc..

Exactly my goal. So the current tree has dijkstra, astar, shooting_star and trsp all in a core library but each in a separate src tree and because of additional dependencies, tsp and dd are in separate libraries but along side the others in the same tree structure.

Right now it is all getting sorted out in the cmake files. Eventually I will probably need to refactor the cmake files, but they are ok for now.

Basically each algorithm is in a tree like:

core/<algorithm>/
   doc/
   sql/
   src/
   test/

Currently, only sql and src are populated, but the basic structure is important as we move forward. Adding a new algorithm is just a matter of creating the tree and adding various CMakeFiles.txt files in each level of the tree and these can basically just mirror any of the parallel branches in the tree. When we start adding doc and tests I'll have to do some more work on the cmake files, but that can wait till I actually can install and test something.

-Steve

Daniel

On Wed, Mar 13, 2013 at 12:13 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

    Hi all,

    I'm making some progress with pgRouting on Win64. I have been able
    to get my source tree to compile which means I have worked through
    the various issues of installing the various dependencies to
    pgRouting. There are still a few minor issues in this regard and
    Sanak is looking into one related to installing boost.

    My source tree is not complete yet from the point of view that it
    still needs changes for:

    1. creating all the postgresql extension files and installing them
    properly
    2. for up grading the SQL to work with postgis 2.0+
    3. testing the installed code
    4. getting everything to work with 32 bit builds

    But getting the dependencies to install and getting the source to
    compile on MinGW64 is a huge step. I have also brought the source
    back to Linux and made a few changes there. So a lot of back and
    forth to keep everything working on both sides.

    Thanks,
       -Steve
    _________________________________________________
    pgrouting-dev mailing list
    pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev&gt;

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/&gt;

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

7

Hi strk,

On 3/13/2013 3:14 AM, Sandro Santilli wrote:

Hi Stephen,
is the branch supposed to be buildable on linux ?

More or less, I have been changing between linux and windows to keep the cmake changes working on both side. It needs me to push some stuff back for linux which will happen later today.

BUT - at this point it is only "buildable", it does not install and has not been tested. I also have a lot of changes to make to it for postgis 2.x compatibility.

I've been trying w/out success two days ago, while I filed a couple
of pull requests to be able to build the "master" branch on Ubuntu 12.04
(hint: waiting for merge :slight_smile:

I have been check changes in most every day.

Should I file tickets for build errors in the 2.0 branch ?
Which branch name, exactly ?

my branch is sew-devel-2_0 and not the devel-2_0. This is a very disruptive restructuring of the source tree. Once that is complete and functioning using the existing code. I will start changing the code to support postgis 2.x and changing how the wrapper functions work and adding some new functionality and replacing some of the dependencies. Well that is my plan, we will see how far I get.

Thanks,
   -Steve

Thanks in advance

--strk;

  http://www.cartodb.com - Map, analyze and build applications with your data

                                        ~~ http://strk.keybit.net

On Tue, Mar 12, 2013 at 11:13:05PM -0400, Stephen Woodbridge wrote:

Hi all,

I'm making some progress with pgRouting on Win64. I have been able
to get my source tree to compile which means I have worked through
the various issues of installing the various dependencies to
pgRouting. There are still a few minor issues in this regard and
Sanak is looking into one related to installing boost.

My source tree is not complete yet from the point of view that it
still needs changes for:

1. creating all the postgresql extension files and installing them properly
2. for up grading the SQL to work with postgis 2.0+
3. testing the installed code
4. getting everything to work with 32 bit builds

But getting the dependencies to install and getting the source to
compile on MinGW64 is a huge step. I have also brought the source
back to Linux and made a few changes there. So a lot of back and
forth to keep everything working on both sides.

Thanks,
   -Steve

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

8

On 3/13/2013 6:03 AM, Dave Potts wrote:

On 13/03/13 04:09, Stephen Woodbridge wrote:
Hi Daniel,

Will you be including any of the other routing code with the 2.0 release
as part of the core offering?

Yes, I have not decided which at this point, but once I get the code tree working again it should be easier for other developers to "claim" a branch of the tree and merge in some additional code.

My KSP stuff follows the same template, with exception of the
documentation which is a single read me file.

Yes, this is one of the algorithms we would like to move into the core.

Are you going to build 32/64 version for Windows as well as Linux?

Yes, that is the plan. At least I want the tree to build in all three environments and I will have the ability to build in windows here so I am also offer windows binaries, I see when I get to that point.

Thanks,
   -Steve

Dave.

On 3/12/2013 11:38 PM, Daniel Kastl wrote:

Thanks, Steve!
The progress is encouraging.

I think it's important that the basic structure is there, so that later
old and new functionality can be added back easily by anyone, who wants
to help. And that it's clearly defined, what needs to be included with
each new algorithm, such as directory structure, tests, documentation,
etc..

Exactly my goal. So the current tree has dijkstra, astar,
shooting_star and trsp all in a core library but each in a separate
src tree and because of additional dependencies, tsp and dd are in
separate libraries but along side the others in the same tree structure.

Right now it is all getting sorted out in the cmake files. Eventually
I will probably need to refactor the cmake files, but they are ok for
now.

Basically each algorithm is in a tree like:

core/<algorithm>/
   doc/
   sql/
   src/
   test/

Currently, only sql and src are populated, but the basic structure is
important as we move forward. Adding a new algorithm is just a matter
of creating the tree and adding various CMakeFiles.txt files in each
level of the tree and these can basically just mirror any of the
parallel branches in the tree. When we start adding doc and tests I'll
have to do some more work on the cmake files, but that can wait till I
actually can install and test something.

-Steve

Daniel

On Wed, Mar 13, 2013 at 12:13 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

    Hi all,

    I'm making some progress with pgRouting on Win64. I have been able
    to get my source tree to compile which means I have worked through
    the various issues of installing the various dependencies to
    pgRouting. There are still a few minor issues in this regard and
    Sanak is looking into one related to installing boost.

    My source tree is not complete yet from the point of view that it
    still needs changes for:

    1. creating all the postgresql extension files and installing them
    properly
    2. for up grading the SQL to work with postgis 2.0+
    3. testing the installed code
    4. getting everything to work with 32 bit builds

    But getting the dependencies to install and getting the source to
    compile on MinGW64 is a huge step. I have also brought the source
    back to Linux and made a few changes there. So a lot of back and
    forth to keep everything working on both sides.

    Thanks,
       -Steve
    _________________________________________________
    pgrouting-dev mailing list
    pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev&gt;

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/&gt;

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

9

My KSP stuff follows the same template, with exception of the
documentation which is a single read me file.

Yes, this is one of the algorithms we would like to move into the core.

Hi Dave,

I have write down a roadmap or better “wish list” in the Wiki some time ago:
https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Plan

As Steve said, the idea is to first get the basics done, define rules/templates for additional functiones, and then it should be easier for anyone to pick one of the “not assigned” functions and add them to pgRouting.
Your contribution is already very well prepared, so it should be one of the easier tasks, and I’m pretty sure it will be one of the first ones added. Of course you’re welcome to help.
At my company we’re super busy this months, but some of us will participate from April. So we promised Steve, that we won’t disturb him in March :wink:

Daniel

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

10

On Wed, Mar 13, 2013 at 08:24:52AM -0400, Stephen Woodbridge wrote:

Hi strk,

On 3/13/2013 3:14 AM, Sandro Santilli wrote:
>Hi Stephen,
>is the branch supposed to be buildable on linux ?

More or less, I have been changing between linux and windows to keep
the cmake changes working on both side. It needs me to push some
stuff back for linux which will happen later today.

BUT - at this point it is only "buildable", it does not install and
has not been tested. I also have a lot of changes to make to it for
postgis 2.x compatibility.

It's not buildable here, with cmake 2.8.7:

-- Configuring done
CMake Error at CMakeLists.txt:139 (ADD_LIBRARY):
  Cannot find source file:

    $<TARGET_OBJECTS:astar>

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

And the same message repeated for:

  $<TARGET_OBJECTS:dijkstra>
  $<TARGET_OBJECTS:shooting_star>
  $<TARGET_OBJECTS:trsp>

Then:

CMake Error in core/astar/src/CMakeLists.txt:
  Cannot find source file:

    OBJECT

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

and the same message repeated for:

CMake Error in core/dijkstra/src/CMakeLists.txt:
CMake Error in core/shooting_star/src/CMakeLists.txt:
CMake Error in core/trsp/src/CMakeLists.txt:

And finally:

-- Build files have been written to: /usr/src/pgrouting/pgrouting/b

With cmake exit code being 1 and `make` returning:

make: *** No targets specified and no makefile found. Stop.

This is invoking cmake from outside the source dir, ie:

mkdir b; cd b; cmake -DWITH_TSP=ON -DWITH_DD=ON ..

With current seq-devel-2_0 (commit 825b40e049e4b21787c27f00aae49b0382279842)

--strk;

11

On 3/13/2013 10:02 AM, Sandro Santilli wrote:

On Wed, Mar 13, 2013 at 08:24:52AM -0400, Stephen Woodbridge wrote:

Hi strk,

On 3/13/2013 3:14 AM, Sandro Santilli wrote:

Hi Stephen,
is the branch supposed to be buildable on linux ?

More or less, I have been changing between linux and windows to keep
the cmake changes working on both side. It needs me to push some
stuff back for linux which will happen later today.

BUT - at this point it is only "buildable", it does not install and
has not been tested. I also have a lot of changes to make to it for
postgis 2.x compatibility.

It's not buildable here, with cmake 2.8.7:

This might be a problem. I'm running cmake version 2.8.10.2 and I might need to up the minimum version to 2.8.10 as I think that is the version that allows you to build obj files in a tree and then assembly them into a single library, which is what I'm doing.

  -- Configuring done
  CMake Error at CMakeLists.txt:139 (ADD_LIBRARY):
   Cannot find source file:

     $<TARGET_OBJECTS:astar>

   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
   .hxx .in .txx

And the same message repeated for:

   $<TARGET_OBJECTS:dijkstra>
   $<TARGET_OBJECTS:shooting_star>
   $<TARGET_OBJECTS:trsp>

Then:

  CMake Error in core/astar/src/CMakeLists.txt:
   Cannot find source file:

     OBJECT

   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
   .hxx .in .txx

and the same message repeated for:

  CMake Error in core/dijkstra/src/CMakeLists.txt:
  CMake Error in core/shooting_star/src/CMakeLists.txt:
  CMake Error in core/trsp/src/CMakeLists.txt:

And finally:

  -- Build files have been written to: /usr/src/pgrouting/pgrouting/b

With cmake exit code being 1 and `make` returning:

  make: *** No targets specified and no makefile found. Stop.

This is invoking cmake from outside the source dir, ie:

  mkdir b; cd b; cmake -DWITH_TSP=ON -DWITH_DD=ON ..

My cmake files were not designed to work outside the source tree. I think all your errors above are a result of this. I didn't think about doing this, but there is no reason that I could support this at some point. I'm very new to working with cmake so suggestions, help and/or pull requests would be appreciated. I suspect that I would need to establish the root of the src tree, then make all the paths absolute or something along those lines. Do you have an example of a project that does this?

With current seq-devel-2_0 (commit 825b40e049e4b21787c27f00aae49b0382279842)

I just pushed a minor fix to add -fPIC so the libraries will link now on linux. 825b40e..209c592 sew-devel-2_0 -> sew-devel-2_0

Thank you for taking the time to test this and report back.

-Steve

--strk;
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

12

On Wed, Mar 13, 2013 at 11:02:25AM -0400, Stephen Woodbridge wrote:

On 3/13/2013 10:02 AM, Sandro Santilli wrote:

>It's not buildable here, with cmake 2.8.7:

This might be a problem. I'm running cmake version 2.8.10.2 and I
might need to up the minimum version to 2.8.10 as I think that is
the version that allows you to build obj files in a tree and then
assembly them into a single library, which is what I'm doing.

It'd be a pity to drop support for older cmake, it's actually already
an annoyance to require cmake :cry:

My cmake files were not designed to work outside the source tree. I
think all your errors above are a result of this. I didn't think
about doing this, but there is no reason that I could support this
at some point. I'm very new to working with cmake so suggestions,
help and/or pull requests would be appreciated. I suspect that I
would need to establish the root of the src tree, then make all the
paths absolute or something along those lines. Do you have an
example of a project that does this?

QGIS does that. But I don't really have tips on using cmake, so far
I've seen _no_ project using cmake and giving the same level of features
you have with autoconf. /me cmake hater :slight_smile:

--strk;

http://strk.keybit.net

13

On 3/13/2013 11:13 AM, Sandro Santilli wrote:

On Wed, Mar 13, 2013 at 11:02:25AM -0400, Stephen Woodbridge wrote:

On 3/13/2013 10:02 AM, Sandro Santilli wrote:

It's not buildable here, with cmake 2.8.7:

This might be a problem. I'm running cmake version 2.8.10.2 and I
might need to up the minimum version to 2.8.10 as I think that is
the version that allows you to build obj files in a tree and then
assembly them into a single library, which is what I'm doing.

It'd be a pity to drop support for older cmake, it's actually already
an annoyance to require cmake :cry:

Yeah, at the moment it was a trade off between upgrading cmake or letting the older version of cmake dictate my source tree layout or learning another way to fake cmake into doing what I need.

I feel that I am spending more time on cmake than on the code at the moment, so I probably will not make any changes now in that direction, but might revisit it in the future if I need to refactor the cmake stuff. There are a lot of moving pieces at this stage, and I need some to be nailed down, even if temporarily so the work does not flounder.

My cmake files were not designed to work outside the source tree. I
think all your errors above are a result of this. I didn't think
about doing this, but there is no reason that I could support this
at some point. I'm very new to working with cmake so suggestions,
help and/or pull requests would be appreciated. I suspect that I
would need to establish the root of the src tree, then make all the
paths absolute or something along those lines. Do you have an
example of a project that does this?

QGIS does that. But I don't really have tips on using cmake, so far
I've seen _no_ project using cmake and giving the same level of features
you have with autoconf. /me cmake hater :slight_smile:

I'm not that fond of it either, but it is what the project has been using. I suppose I could drop it all together, but that might be a bigger issue for some people than having to upgrade to the latest version.

This is still early stages in the project.

-Steve

14

On Wed, Mar 13, 2013 at 11:33:19AM -0400, Stephen Woodbridge wrote:

I'm not that fond of it either, but it is what the project has been
using. I suppose I could drop it all together, but that might be a
bigger issue for some people than having to upgrade to the latest
version.

For CREATE EXTENSION the PostgreSQL PGXS mechanism should help pretty much.
You could check out PostGIS for examples.

--strk;

15

My cmake files were not designed to work outside the source tree. I
think all your errors above are a result of this. I didn’t think
about doing this, but there is no reason that I could support this
at some point. I’m very new to working with cmake so suggestions,
help and/or pull requests would be appreciated. I suspect that I
would need to establish the root of the src tree, then make all the
paths absolute or something along those lines. Do you have an
example of a project that does this?

QGIS does that. But I don’t really have tips on using cmake, so far
I’ve seen no project using cmake and giving the same level of features
you have with autoconf. /me cmake hater :slight_smile:

I’m not that fond of it either, but it is what the project has been using. I suppose I could drop it all together, but that might be a bigger issue for some people than having to upgrade to the latest version.

Hi Sandro,

There are also people, who like CMake, I think :wink: … I’m pretty neutral, mainly because I don’t know well enough about it.
I remember when pgRouting used CMake for the first time and I liked it better that time.

Anyway, this is not something written to stone, so if there are good reasons not to use CMake, then we can talk about alternatives.
I remember to have talked with Paul Ramsey at previous FOSS4G and he said, that PostGIS might use CMake in the future.
But I don’t know if this is still the case. Probably you know better, if there are any plans.

Daniel

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

16

On Thu, Mar 14, 2013 at 12:46:53AM +0900, Daniel Kastl wrote:

There are also people, who like CMake, I think :wink: ... I'm pretty neutral,
mainly because I don't know well enough about it.
I remember when pgRouting used CMake for the first time and I liked it
better that time.

Anyway, this is not something written to stone, so if there are good
reasons not to use CMake, then we can talk about alternatives.
I remember to have talked with Paul Ramsey at previous FOSS4G and he said,
that PostGIS might use CMake in the future.
But I don't know if this is still the case. Probably you know better, if
there are any plans.

The real reason why people to use CMake is to make building for Windows easier.
Usually this has meant, for some years now, making building on free operating
systems harder.

That said, I dubt PostGIS will move to cmake unless someone steps up to
maintain the cmake build system. Someone has tried but never completed the
task. Evidently there's nobody needing cmake enough to work on it.

--strk;

17

Hi Sandro,

Daniel has modifed our cmake files so we can now build outside the source tree.

cmake -H. -Bmybuild -DWITH_TSP=ON -DWITH_DD=ON -DWITH_DOC=ON
cd mybuild && make

Where -B <dir> - where the build tree will be created (build)
       -H <dir> - where the project source tree is located (home)

You can build it "in" a sub-dir in the source tree or put the source tree elsewhere.

Thank you for the suggestion.

-Steve

On 3/13/2013 10:02 AM, Sandro Santilli wrote:

On Wed, Mar 13, 2013 at 08:24:52AM -0400, Stephen Woodbridge wrote:

Hi strk,

On 3/13/2013 3:14 AM, Sandro Santilli wrote:

Hi Stephen,
is the branch supposed to be buildable on linux ?

More or less, I have been changing between linux and windows to keep
the cmake changes working on both side. It needs me to push some
stuff back for linux which will happen later today.

BUT - at this point it is only "buildable", it does not install and
has not been tested. I also have a lot of changes to make to it for
postgis 2.x compatibility.

It's not buildable here, with cmake 2.8.7:

  -- Configuring done
  CMake Error at CMakeLists.txt:139 (ADD_LIBRARY):
   Cannot find source file:

     $<TARGET_OBJECTS:astar>

   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
   .hxx .in .txx

And the same message repeated for:

   $<TARGET_OBJECTS:dijkstra>
   $<TARGET_OBJECTS:shooting_star>
   $<TARGET_OBJECTS:trsp>

Then:

  CMake Error in core/astar/src/CMakeLists.txt:
   Cannot find source file:

     OBJECT

   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
   .hxx .in .txx

and the same message repeated for:

  CMake Error in core/dijkstra/src/CMakeLists.txt:
  CMake Error in core/shooting_star/src/CMakeLists.txt:
  CMake Error in core/trsp/src/CMakeLists.txt:

And finally:

  -- Build files have been written to: /usr/src/pgrouting/pgrouting/b

With cmake exit code being 1 and `make` returning:

  make: *** No targets specified and no makefile found. Stop.

This is invoking cmake from outside the source dir, ie:

  mkdir b; cd b; cmake -DWITH_TSP=ON -DWITH_DD=ON ..

With current seq-devel-2_0 (commit 825b40e049e4b21787c27f00aae49b0382279842)

--strk;
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

18

On Sun, Mar 24, 2013 at 10:19:03AM -0400, Stephen Woodbridge wrote:

Hi Sandro,

Daniel has modifed our cmake files so we can now build outside the
source tree.

cmake -H. -Bmybuild -DWITH_TSP=ON -DWITH_DD=ON -DWITH_DOC=ON
cd mybuild && make

Where -B <dir> - where the build tree will be created (build)
      -H <dir> - where the project source tree is located (home)

Could the -B switch be optional, defaulting to $PWD, and the source
tree be possibly specified without a switch ? That'd make the cmake
interface similar to the standard ./configure line:

mkdir mybuild; cd mybuild; cmake .. && make

This is how qgis cmake build works, for example.

Also, does this still require cmake 2.8.10 ?

--strk;

You can build it "in" a sub-dir in the source tree or put the source
tree elsewhere.

Thank you for the suggestion.

-Steve

On 3/13/2013 10:02 AM, Sandro Santilli wrote:
>On Wed, Mar 13, 2013 at 08:24:52AM -0400, Stephen Woodbridge wrote:
>>Hi strk,
>>
>>On 3/13/2013 3:14 AM, Sandro Santilli wrote:
>>>Hi Stephen,
>>>is the branch supposed to be buildable on linux ?
>>
>>More or less, I have been changing between linux and windows to keep
>>the cmake changes working on both side. It needs me to push some
>>stuff back for linux which will happen later today.
>>
>>BUT - at this point it is only "buildable", it does not install and
>>has not been tested. I also have a lot of changes to make to it for
>>postgis 2.x compatibility.
>
>It's not buildable here, with cmake 2.8.7:
>
> -- Configuring done
> CMake Error at CMakeLists.txt:139 (ADD_LIBRARY):
> Cannot find source file:
>
> $<TARGET_OBJECTS:astar>
>
> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
> .hxx .in .txx
>
>And the same message repeated for:
>
> $<TARGET_OBJECTS:dijkstra>
> $<TARGET_OBJECTS:shooting_star>
> $<TARGET_OBJECTS:trsp>
>
>Then:
>
> CMake Error in core/astar/src/CMakeLists.txt:
> Cannot find source file:
>
> OBJECT
>
> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
> .hxx .in .txx
>
>and the same message repeated for:
>
> CMake Error in core/dijkstra/src/CMakeLists.txt:
> CMake Error in core/shooting_star/src/CMakeLists.txt:
> CMake Error in core/trsp/src/CMakeLists.txt:
>
>And finally:
>
> -- Build files have been written to: /usr/src/pgrouting/pgrouting/b
>
>With cmake exit code being 1 and `make` returning:
>
> make: *** No targets specified and no makefile found. Stop.
>
>This is invoking cmake from outside the source dir, ie:
>
> mkdir b; cd b; cmake -DWITH_TSP=ON -DWITH_DD=ON ..
>
>With current seq-devel-2_0 (commit 825b40e049e4b21787c27f00aae49b0382279842)
>
>--strk;
>_______________________________________________
>pgrouting-dev mailing list
>pgrouting-dev@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--

http://www.cartodb.com - Map, analyze and build applications with your data

                                       ~~ http://strk.keybit.net

19

On 3/25/2013 12:15 PM, Sandro Santilli wrote:

On Sun, Mar 24, 2013 at 10:19:03AM -0400, Stephen Woodbridge wrote:

Hi Sandro,

Daniel has modifed our cmake files so we can now build outside the
source tree.

cmake -H. -Bmybuild -DWITH_TSP=ON -DWITH_DD=ON -DWITH_DOC=ON
cd mybuild && make

Where -B <dir> - where the build tree will be created (build)
       -H <dir> - where the project source tree is located (home)

Could the -B switch be optional, defaulting to $PWD, and the source
tree be possibly specified without a switch ? That'd make the cmake
interface similar to the standard ./configure line:

  mkdir mybuild; cd mybuild; cmake .. && make

This is how qgis cmake build works, for example.

Also, does this still require cmake 2.8.10 ?

--strk;

OK, I just tried it as you suggest and it works also without using the -B and -H option. I have not tried it on other versions than 2.8.10, I'll have to look at what forced us to use this and see if we can work around it, but I suspect not.

-Steve

You can build it "in" a sub-dir in the source tree or put the source
tree elsewhere.

Thank you for the suggestion.

-Steve

On 3/13/2013 10:02 AM, Sandro Santilli wrote:

On Wed, Mar 13, 2013 at 08:24:52AM -0400, Stephen Woodbridge wrote:

Hi strk,

On 3/13/2013 3:14 AM, Sandro Santilli wrote:

Hi Stephen,
is the branch supposed to be buildable on linux ?

More or less, I have been changing between linux and windows to keep
the cmake changes working on both side. It needs me to push some
stuff back for linux which will happen later today.

BUT - at this point it is only "buildable", it does not install and
has not been tested. I also have a lot of changes to make to it for
postgis 2.x compatibility.

It's not buildable here, with cmake 2.8.7:

  -- Configuring done
  CMake Error at CMakeLists.txt:139 (ADD_LIBRARY):
   Cannot find source file:

     $<TARGET_OBJECTS:astar>

   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
   .hxx .in .txx

And the same message repeated for:

   $<TARGET_OBJECTS:dijkstra>
   $<TARGET_OBJECTS:shooting_star>
   $<TARGET_OBJECTS:trsp>

Then:

  CMake Error in core/astar/src/CMakeLists.txt:
   Cannot find source file:

     OBJECT

   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
   .hxx .in .txx

and the same message repeated for:

  CMake Error in core/dijkstra/src/CMakeLists.txt:
  CMake Error in core/shooting_star/src/CMakeLists.txt:
  CMake Error in core/trsp/src/CMakeLists.txt:

And finally:

  -- Build files have been written to: /usr/src/pgrouting/pgrouting/b

With cmake exit code being 1 and `make` returning:

  make: *** No targets specified and no makefile found. Stop.

This is invoking cmake from outside the source dir, ie:

  mkdir b; cd b; cmake -DWITH_TSP=ON -DWITH_DD=ON ..

With current seq-devel-2_0 (commit 825b40e049e4b21787c27f00aae49b0382279842)

--strk;
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

20

cmake -H. -Bmybuild -DWITH_TSP=ON -DWITH_DD=ON -DWITH_DOC=ON
cd mybuild && make

Where -B - where the build tree will be created (build)
-H - where the project source tree is located (home)

Could the -B switch be optional, defaulting to $PWD, and the source
tree be possibly specified without a switch ? That’d make the cmake
interface similar to the standard ./configure line:

If you don’t specify -B then the current directory is assumed.
I tried to set a default build directory, but this seems to be impossible with CMake. It seems CMake already performs several tasks already before looking at CMakeLists.txt

So if you don’t pay attention and run cmake in the project source, you mess up the source tree.
(though you can do a cleanup with “make distclean”)

mkdir mybuild; cd mybuild; cmake … && make

This is how qgis cmake build works, for example.

I will try this out and if it’s possible to make this default.

Also, does this still require cmake 2.8.10 ?

Yes, it would be nice if there wouldn’t be a requirement for such a recent version of CMake,
I even had to compile for Ubuntu.

Daniel

–strk;

You can build it “in” a sub-dir in the source tree or put the source
tree elsewhere.

Thank you for the suggestion.

-Steve

On 3/13/2013 10:02 AM, Sandro Santilli wrote:

On Wed, Mar 13, 2013 at 08:24:52AM -0400, Stephen Woodbridge wrote:

Hi strk,

On 3/13/2013 3:14 AM, Sandro Santilli wrote:

Hi Stephen,
is the branch supposed to be buildable on linux ?

More or less, I have been changing between linux and windows to keep
the cmake changes working on both side. It needs me to push some
stuff back for linux which will happen later today.

BUT - at this point it is only “buildable”, it does not install and
has not been tested. I also have a lot of changes to make to it for
postgis 2.x compatibility.

It’s not buildable here, with cmake 2.8.7:

– Configuring done
CMake Error at CMakeLists.txt:139 (ADD_LIBRARY):
Cannot find source file:

$<TARGET_OBJECTS:astar>

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

And the same message repeated for:

$<TARGET_OBJECTS:dijkstra>
$<TARGET_OBJECTS:shooting_star>
$<TARGET_OBJECTS:trsp>

Then:

CMake Error in core/astar/src/CMakeLists.txt:
Cannot find source file:

OBJECT

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

and the same message repeated for:

CMake Error in core/dijkstra/src/CMakeLists.txt:
CMake Error in core/shooting_star/src/CMakeLists.txt:
CMake Error in core/trsp/src/CMakeLists.txt:

And finally:

– Build files have been written to: /usr/src/pgrouting/pgrouting/b

With cmake exit code being 1 and make returning:

make: *** No targets specified and no makefile found. Stop.

This is invoking cmake from outside the source dir, ie:

mkdir b; cd b; cmake -DWITH_TSP=ON -DWITH_DD=ON …

With current seq-devel-2_0 (commit 825b40e049e4b21787c27f00aae49b0382279842)

–strk;

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–

http://www.cartodb.com - Map, analyze and build applications with your data

~~ http://strk.keybit.net

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de