Это больше относится к возможностям самой базы а не к этой утилите.
Никак, разумеется 
Есть, конечно, некие скрипты http://www.cmake.org/Wiki/CMake#Visual_Studio , но всё рано не работавшему с cmake он вряд ли сильно помогут.
Если писать под Linux без системных вызовов, то под Windows проще будет скомпилировать (mingw и т.д.), но производительность пострадает, хотя бы немного. Портировать в другую сторону значительно сложнее.
Нормальной кроссплатформенной многопоточности без кучи библиотек типа Qt до сих пор нет.
http://stackoverflow.com/questions/2561471/is-there-any-cross-platform-threading-library-in-c
Более-менее работает только OpenMP, но он специализированный (под параллельные вычисления).
Так что скажите спасибо автору, что проект не использует MFC/ATL/ COM / и т.д.
Универсализация кода - день работы программиста, пользовавшегося CMake и подходящей многопоточной библиотекой.
(я к таким, к счастью своему, не отношусь)
Якобы стандартный Boost или С++11 тоже не сахар, мягко говоря, хотя может и сойти. Если охота попроще - SDL-потоки… Для фанатов - Posix threads.
Заставлять это делать одного автора считаю бессмысленным, т. к. это нужно другим людям. Разве что сам захочет освоить Boost)) А если портировать действительно нужно - соавтор найдётся.
Может ведь оказаться, что индексы Spatialite, на которые он тратит время - это как раз самое нужное для дальнейшего использования ))
извините за оффтоп…
Ivan Komarov, AMDmi3, akks - допустим я решил писать что-то с нуля в Win32, консольное, однопоточное, с перспективой платформонезависимости. Какой кроссплатформенный IDE и компилятор установить (желательно с минимум телодвижений), чтобы получить нормальный проект и делиться им с линуксоидами ? Нужна пошаговая отладка и сборка напрямую из IDE, всё-таки 21-й век на дворе. Заранее спасибо !
На взгляд теоретика неплоха связка CodeBlocks + MinGW (который свежий фиг достать).
Я Qt качаю и использую, но это Gui. Там в комплекте mingw+среда QtCreator (чистую консоль без Qt тоже можно делать).
Для тру-плюсовиков - CMake и генерация проекта VisualStudio (и аккуратность в использовании библиотек). Готовые проекты открывать действительно нетрудно, свои не создавал (коллеги говорят, что не сильно сложно…). QtCreator их тоже открывает.
/offtop
В баню плюсы переходите на Mono 
Давай сравним её с инструкцией к osm2dcm 
На java тогда уж. 
Немного почитав про CMake понял следуещее
Скармливаю свой проект утилите http://vcproj2cmake.sourceforge.net/ она сформирует файл CMakeList.txt.
Я его кладу в проект и всё!
Ура, мой проект стал кроссплатформенным!
Давай. Инструкция-то к ней очень простая.
1a. Скачай готовые карты с сайта и залей на устройство.
2b. На ондроиде нажми на карту в загрузчике, и она сама загрузится.
2. Пользуйся.
А как собрать его под iOS?
Ага, только это не инструкция к osm2dcm. Где описание, как развернуть его у себя?
Да-да, конечно ))))) А попробовать сгенерировать?
Не нужно никаких кроссплатформенных IDE и компиляторов, разрабатывайте и отлаживайтесь в чём привыкли. Для переносимости важно как вы пишите код, а не в чём.
Хорошая программа - это программа которая максимально эффективно решает бизнес-задачу пользователя. Все остальное - детали реализации.
Я High Performance Computing 13 лет в общей сложности занимаюсь. В чем-то вы правы, не задумываюсь - уже рефлекс.
Ага, ей - 3 года
Работает.
Это так - описываете сборку в CMake, который может генерировать “проект” хоть для VS, хоть для Eclipse, хоть голый makefile (который в Винде тоже прекрасно работает). Дальше работаете в своем любимом IDE и в ус не дуете.
Если речь идет о Win/Linux/Mac, то у меня выработался такой подход.
Проект либо стартую в VS, а потом, по мере необходимости, пишу CMake, либо сразу начинаю с CMake. CMake, как уже сказали, может генерировать файлы проекта для основных распространенных IDE, тут единственное неудобство - вносить изменения в него, а не напрямую в студии, иначе они будут потеряны. При разработке никаких особых танцев с бубном не предпринимаю, но не использую системные API, оставаясь в рамках стандартного С++. VS 2012 (включая express edition) и g++ с их частичной поддержкой стандарта С++11 позволяют сделать удивительно много, не прибегая к системно-зависимым вещам. Если утыкаюсь в проблему, неразрешимую в рамках Стандарта - смотрю в сторону boost, там многие полезные вещи уже реализованы, скажем работа с файловой системой. При необходимости GUI - который я стараюсь максимально изолировать от “ядра” - использую Qt. Графика - на OpenGL, при переносе очень мало проблем.
После получения работающего варианта, вздохнув, лезу в Linux и собираю из CMake’а проект. Обычно g++ вылавливает пару ошибок/неточностей, пропущенных VS и ругается на какую-нибудь шаблонную конструкцию. Исправляю. В случае Mac’а иногда приходится подсовывать альтернативные заголовки с помощью #ifdef. Проверяю, не накрылась ли компиляция в Windows.
В отдельных случаях приходится вставлять #ifdef-обертки в код, если есть ограничение использовать устаревший компилятор. Скажем, недавно парился с _finite, для тайминга обертку свою использую. Изменения, связанные с портированием под Linux, обычно настолько незначительны, что вношу исправления в текстовом редакторе, не заморачиваясь с IDE. Если б портировал в обратном направлении - не заморачивался бы с VS в Windows
Да, чуть не забыл! Обязательно использовать систему контроля версий (git), иначе будут большие сложности с синхронизацией кода.
Для проекта, на разработку которого ушло несколько месяцев, портирование обычно выполняю за день.
Если есть желание и IDE кроссплатформенную использовать - можно посмотреть в сторону Eclipse или CodeBlocks. Какое-то время я так работал, но потом вернулся к основной разработке в VS.
Совокупный overhead для разработки кроссплатформенных проектов у меня, после выработки навыков, наверное не больше 15%.
2 akks: Ваш скепсис в отношение многопоточности в С++11 и boost мне непонятен, меня она абсолютно устраивает. Да и идеи в-основном позаимствованы из posix threads. Если хочется чего-то более высокоуровневого - есть Intel TBB, рекоммендую. Также замечу, что портировать Linux-specific приложение тоже не сахар. К моему сожалению, в научном сообществе редко кто парится о платформонезависимости, поэтому используют свои любимые системные API везде, где без них можно спокойно обойтись. Я вот только не понимаю, зачем? Ровно столько же усилий потребовалось бы на написание этого кода в рамках Стандарта. Поэтому мне часто грустно от несовершенства мира.
Отрадно слышать, что этим наконец-то стало можно пользоваться.
У меня, наверное, данные устарели на пару лет. Тогда программы с boost не компилировались практически ничем, кроме голого gcc специфической версии, а C++11 был реализован на уровне фантазий разработчиков компилятора (студию 2012 поставил неделю назад, до этого жил с 2008, а писал практически только на Java). Идеи многопоточности всюду похожие, кроме совсем экзотических вариантов.
TBB - это хорошо, согласен. Математические библиотеки Intel, кстати, тоже иногда ускоряют программу в десятки раз по сравнению с самописными велосипедами (это для не знакомых с HPC пишу).
А в Boost есть ещё библиотека для графов и куча готовых алгоритмов, включая Дейкстру и A*. Правда, разобраться в чём-то сложнее Hello World с непривычки почти невозможно (если пользовались STL-легче) из-за обилия шаблонов, итераторов и прочей плюсовой ереси специфики, без которой большинство непрофессиональных С++ кодеров прекрасно обходится (и программа имеет культурный C-вид).
Сорри за оффтоп.
Ivan Komarov
Правильно ли я понимаю что конфиги для CMake пишутся обычным текстовым редактором ? Т.е. надо изучать ещё один “язык” ? Или есть какой-нибудь GUI-wrapper ?
У меня появилась идея с чего начать изучение CMake - использовать его для компиляции карт вместо батников (выкачать страну, обновить часовыми диффами, обрезать, osm2mp, mp-postprocess, компиляция в нужный формат, upload готовой карты на сервер). Всё сложнее и сложнее отслеживать зависимости и поддерживать разные платформы (Навител, Ситигид и пр.); cmake, если я правильно понимаю, всё сделает сам ?
Нет, это именно инструкция. Никому же не приходит в головову называть инструкцией к потлачу описание, как развернуть его у себя на сервере. Если кто-то захочет поднять osm2dcm у себя, у него один выход - выклянчить у меня виртуалку. С некоторых пор там даже ppm не помогает.
К чему я это все. Кросплатформенное приложение (которое пользователи в самом деле могут запускать на разых платформах) и кросплатформенный код (который программисты могут портировать, если вдруг захотят) - две большие разницы.
А! То есть готовая среда нам даётся свыше
Ну тогда к osm2mp инструкция будет ещё проще:
- запустите из командной строки “perl osm2mp.pl”
CMake - это, грубо говоря, настраиваемый генератор makefile-ов, а также проектов для IDE. Берёт параметры, смотрит, что есть в системе на привычных местах, и строит из этого инструкцию для сборки. Сам при этом ничего не собирает. (аналог более древних традиционных для Unix configure-скриптов).
Чтобы научить его находить новую библиотеку или там наличие рабочего софта конвертации, необходимы танцы с бубном и дописывание своих модулей по аналогии с Find***. Существующие заточены под С/C++.
Так что для сборки карт, на мой взгляд, если батников не хватает, лучше уж переходить на Python-скрипты. A если нужно хитрое управление зависимостями, на что-то типа Gradle (cам не использовал).