[pgrouting-dev] pgRouting 2.0 using OSX homebrew

sanak geosanak at gmail.com
Tue May 7 15:05:44 PDT 2013


Hi Alec, Stephen,

About 1 month ago, I tried Mac ports build in my private branch("macports")
which is based on "sew-revel-2_0",
and confirmed that it can build with Mac OSX 10.8(Mountain Lion).
https://github.com/sanak/pgrouting4w/commit/7291a7b6be3bd37c9e507048bfe3ba0fcf0c5c6e

Now, I am busy for other task, but, I will check and test it in this
weekend.



2013/5/8 Stephen Woodbridge <woodbri at swoodbridge.com>

> On 5/7/2013 10:27 AM, Alec Gosse wrote:
>
>> Hello all,
>>
>> I am working on a bicycle routing project and converting from Open
>> Trip Planner to pgRouting on both OSX and 64bit Ubuntu with
>> PostgreSQL 9.1+. For me, the sew-revel-2_0 branch will build under
>> ubuntu 12.10, but not on OSX 10.8 using dependencies installed
>> through Homebrew.
>>
>> Homebrew is certainly the best way I've found to install open-source
>> tools on a mac, so I would like to help get pgRouting 2.0 installable
>> that way. Homebrew tends to use quite current packages such as boost
>> 1.53, however, but I see in tool/NOTES.txt that pgRouting requires
>> boost 1.46.1? Since things build on Ubuntu using boost 1.49, I'm
>> wondering if this still applies?
>>
>
> Well the required version is whatever you can get to work. I know there
> are some problems with 1.47, but those might be specific to that version.
>
>
>  In either case, what's the best way for me to help get things running
>> under OSX? Should I post errors I can't resolve to the list, and or
>> is someone already working on this?
>>
>
> Yes, We can try to help if we know what errors you are seeing. I'm not
> sure anyone here has OSX so you might need to take some initiative to
> figure things out. If you look at the CMakeLists.txt files that are
> sprinkled throughout the project tree, you will see that some of them have
> blocks like:
>
> if(APPLE)
> ...
> endif(APPLE)
>
> maybe we don't have these setup correctly or maybe some are missing that
> need to be added. It would be great if you can help with this.
>
> Thanks,
>   -Steve
>
>
>  Best, Conrad (Alec) Gosse, MUEP Doctoral Candidate: Civil &
>> Environmental Engineering University of Virginia Charlottesville, VA
>>
>> On May 7, 2013, at 1:40 AM, Daniel Kastl <daniel at georepublic.de>
>> wrote:
>>
>>  Hi Razequl,
>>>
>>> The currently used branch is named "sew-devel-2_0" (we're planning
>>> to rename it to "develop" some time). You find all the necessary
>>> steps to compile explained on the Github readme:
>>> https://github.com/pgrouting/**pgrouting/tree/sew-devel-2_0<https://github.com/pgrouting/pgrouting/tree/sew-devel-2_0>
>>>
>>> If you want to compile with support for "Driving Distance", then
>>> you need to have CGAL libraries as dependency. GAUL dependency is
>>> gone.
>>>
>>> Daniel
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 7, 2013 at 2:35 PM, Razequl Islam
>>> <ziboncsedu at gmail.com> wrote: Hi Steve, I also want to have a look
>>> at the possible problem. I am trying to set up the environment on
>>> my machine. I have the previous version. What do I need to do to
>>> get 2.0 working? Should I set up the environment from the scratch
>>> or should an update will do. Please let me know how I should
>>> proceed. I can also do the debugging once I have the environment in
>>> place.
>>>
>>> Thanks. - Razequl
>>>
>>>
>>>
>>> On Mon, May 6, 2013 at 11:32 PM, Stephen Woodbridge
>>> <woodbri at swoodbridge.com> wrote: Hi Razequl,
>>>
>>> I have been trying to integrate your bidirectional shortest path
>>> code. I have merged the code into my pgrouting branch
>>> "sew-devel-2_0", but it is crashing the back-end with a segv.
>>>
>>> If you have time and want to look into this that would be great as
>>> I would like to get this code working in 2.0.
>>>
>>> I'm not sure if I found a bug in your code or I broke something
>>> when I merged it, or for that matter that I even merged the correct
>>> code :) because you sent email indicating that you fixed stuff. I
>>> merged the code from master at https://github.com/zibon/**pgrouting<https://github.com/zibon/pgrouting>
>>>
>>> I also ran into an issue that when I merged you code into the code
>>> library, that the trsp broke, then take you code out and it works
>>> again. I assume that there is some kind of function name or global
>>> initialization issue. This does not seem to be an issue for trsp
>>> now that the bi-dir code is in a separate library.
>>>
>>> This might give you a chance to get your development/test/debug
>>> environment setup and to familiarize yourself with the new source
>>> code layout.
>>>
>>> Let me know if you have time and I'll help point the way. If you
>>> are tied up with class work, etc that clearly takes priority.
>>>
>>> Thanks, -Steve
>>>
>>>
>>> ______________________________**_________________ pgrouting-dev
>>> mailing list pgrouting-dev at lists.osgeo.org
>>> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>>>
>>>
>>>
>>>
>>> -- Georepublic UG & Georepublic Japan eMail:
>>> daniel.kastl at georepublic.de Web: http://georepublic.de
>>> ______________________________**_________________ pgrouting-dev
>>> mailing list pgrouting-dev at lists.osgeo.org
>>> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>>>
>>
>> ______________________________**_________________ pgrouting-dev mailing
>> list pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>>
>>
> ______________________________**_________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20130508/499da59d/attachment-0001.html>


More information about the pgrouting-dev mailing list