ОК, добавил в обе сборки. Не у всех же Windows 8
Если ругается при запуске - правьте data/.stxxl блокнотом - путь к временному файлу и объём в Мб должны быть правильными (по умолчанию 10 гб в d:/temp).
Кстати - извиняюсь, под Windows XP не заработает (VS2012 требует для этого отдельных танцев с бубном, завтра попробую).
А где можно увидеть исправления в коде, позволившие такую компиляцию?
И какие версии библиотек использовались?
Просто я сам пытался откомпилить, и даже откомпилилось после плясок с бубном, но не заработало В итоге было принято политическое решение оставаться на линухе.
Если учесть, что мне нужна собственная версия с модифицированным кодом - буду весьма признателен за необходимые патчи к оригиналу.
Dennis обещал внедрить, когда доберётся до чьей-нибудь машины c Visual Studio
Библиотеки:
Boost (лучше свежий, инструкции по сборке VS в сети есть)
libz, bzip2 и libxml2 (дистрибутивы и инструкции с оф. сайтов, проблем не было)
Google Protobuf 2.5 (в комплекте есть проект Visual Studio)
stxxl (только c svn!) - есть makefile-ы и проект, в настройках врубаем boost и прописываем BOOST_ROOT
osmpbf - либо вручную, либо моим cmake-вариантом (нужно сказать, где лежит protobuf): https://github.com/alex85k/OSM-binary
(если ругается - закомментировать строчку add_subdirectory(tools) в CMakeLists.txt)
luabind : заработало с обновленным сторонним вариантом https://github.com/Oberon00/luabind
(сборка через cmake, ссылаемся на .lib и include от Lua и прописываем BOOST_ROOT и при необходимости Boost_USE_STATIC_LIBS )
Скомпилированыые библиотеки складываем в какую-то папку (CMake - запускаем проект INSTALL, предварительно CMAKE INSTALL DIR в cmake-gui).
Сам OSRM с исправленным кодом собирается тоже CMake-ом с ручным указанием всех путей к библиотекам в cmake-gui . Он на них по очереди ругается и мы в ответ прописываем путь к include и lib файлам вручную (стандартных путей для них под Windows не предусмотрено, так что - ко всем 9 библиотекам). При сборке около 500 Warning-ов (в основном stxxl)
Под Linux-ом или FreeBSD всё намного легче, но luabind и stxxl всё равно иногда приходится собирать руками (если в репозиториях их нет или они ругаются прир компиляции из-за протухания).
А не работает откомпиленный OSRM обычно из-за отсутствия файлика .stxxl с указанием временного файла или папки profile . Ну и раньше 64-бит ID из xml неправильно читало.
Спасибо!
У меня как раз на stxxl падал, где-то в потрохах. Про версию (только c svn!) - это существенно. C файлом “.stxxl” я разобрался достаточно быстро, патч 64-bit ID вы сделали уже давно. Но все равно падало.
luabind тоже много крови попил, этот форк я не находил.
Кстати, быстродействие виндовой версии не сверяли с линуксом на таком же железе?
У меня FreeBSD на виртуалке, но работает примерно с той же скоростью… В Ubuntu перезагрузиться и всё пересобрать пока некогда…
Кстати, для скорости можно ещё поставить luajit (с недавних пор поддерживается) и скомпилировать stxxl с параллельностью (но я уже не стал мучаться). И компилятор Intel, наверное, помог бы (под Linux тоже, кстати, там он даже бесплатный/non-commercial есть)…
Lua там только в экстракте участвует, для роутинга не нужен, как я понимаю.
stxxl с параллельностью большого прироста не даст - алгоритмы линейные.
А вот скорость работы с диском может от оси зависеть очень сильно.
Насчет интела не уверен - вроде в каких-то тестах vc2012 его даже делал.
На виртуалке у меня был ubuntu server, вживую - ubuntu 13.04. Живой линух виртуалку раза в 1.5 превосходит. При этом на машине 8 гиг, виртуалке давал 6.
Откомпилил, однако… Надо было сначала проверить.
Не работает роутинг под виндой. Вот этот “маршрут” и под линуксом, и на основном сервере показывается совершенно нормально.
Под виндой же - что попало. Причем если брать данные, сконверченные на линухе - все равно что попало, т.е. ошибка именно в роутинге. И на моем бинарнике, и на вашем.
Да, печально. Проверил - всё так и есть (уезжает разворачиваться куда попало). C debug-ом там вообще тяжело, библиотеки же отладочные надо (+рабочая папка меняется)…
Можно для гарантии проверить osrm-routed под Linux, собранный из Windows-совместимых исходников… (проверяю на BSD)
(Может, патч кривоват? Вряд ли, конечно. Скорее всего, какое-нибудь преобразование типов по-другому сработало…)
Если кто-то из заинтересованных спецов С++ может найти ошибку или несовместимость c VisualStudio в коде OSRM, приводящую к странным маршрутам - добро пожаловать! https://github.com/DennisOSRM/Project-OSRM/issues/671
Из-за этого глюка OSRM под Windows неюзабелен… (мне казалось, что в ранней сборке ошибок не было, но это, наверное, не так). У автора нет доступа к VisualStudio (палёным в их краях не пользуются), так что вся надежда на вас )
Пересобрал ещё раз с помощью Windows 7 SDK из консоли (вот мои батники: https://dl.dropboxusercontent.com/u/63393258/Build_OSRM.zip ) .
extract и prepare стали иногда вылетать, но баг в routed, кажется, куда-то испарился ))
Сборная сборка (2 старых exe +1 новый) на дропбоксе (32 бит не обновлял).
Автору OSRM доложил, он собирается всё проверить и починить.
был неудачным решением с беззнаковыми длинными числами (long long добавил я из-за ошибки компилятора VS2012)…
Старый бесплатный компилятор из Windows 7 SDK этого не переварил и заставил исправить.
Итог - сборка работает (снова VS2012), Dennis перепроверяет для включения патчей в основную ветку.
P.S. 32бит тоже пересобрал. Желающие могут пособирать и сами - вот скрипты (нужен только ms-компилятор, git, svn, cmake и собранный boost)