С заменой не так всё просто. При переходе с wchar_t на char мы теряем полноценную поддержку имен файлов в windows. Будет невозможно передать любое имя файла в параметрах приложения. Будут существовать имена которые консольное приложение не скушет. Для линуха как я понимаю такой проблемы нет.
Единственное правильное решение это применять _TCHAR. Или я чего то не понимаю? Разве кроссплатформенные консольные приложения под wиндами кушают все файлы?
Покопался в этом, сложилась следующая картина:
Чтобы передать Unicode’ную строку в main в Windows, действительно, нужно использовать wmain. Который, в свою очередь, не переносим.
Поэтому тут нужна препроцессорная магия для генерирования правильного имени “main’а”. Далее используем boost::filesystem. Например:
#ifdef WIN32
#define MAIN wmain
typedef wchar_t unicode_char;
#else
#define MAIN main
typedef char unicode_char;
#endif
int MAIN(int argc, const unicode_char* argv[]){
boost::filesystem::ifstream iFile(argv[1]);
assert(iFile.is_open());
return 0;
}
Если в windows поддержку юникода ввели по пути ломания совместимости с вообще всем что существует, то придётся либо вставлять #ifdef на все различия (char/wchar_t, main/_tmain, fopen/_wfopen, sqlite_open/sqlite_open16 и т.д.), либо использовать обёртки над этими особенностями (как было предложено, boost), либо оставаться с 8bit. Тут все три подхода вполне применимы, вопрос в меньшем зле.
Вот это не советую. Потом откуда-нибудь придут, скажем, немцы и попросят умляуты - тут можно совсем закопаться с кодировками.
Так у немцев есть своя 1250 с умляутами и ß.
Тоже верно. Но, боюсь, приспичит кому-нибудь рано или поздно с разными языками одновременно работать 
Наконец то готова мультиплатфоменная версия. Проверял сборку под VS2008 и Code::Blocks под убунтой.
- Под MSVC работает PCH.
- Под линухом так и не смог настроить предкомпиляцию заголовков. Чото нехватает в знаниях cmake+gcc.
Отлично!
PCH под Linux - всё ещё экзотика
Попытка пересоздать проект для VS2012 выявляет следующие сложности для непосвященных типа меня:
-
Не находит Boost, если не установлен BOOST_ROOT. Попытка изменить Boost_DIR не завершается успехом.
Нужно догадаться по ошибкам добавить BOOST_ROOT (cmake не любит очень любит boost? к файлу проекта тут претензий нет… ) -
Zlib - нужно догадаться поменять ZLIB_LIBRARY = … .lib ZLIB_INCLUDE_DIR = … /include в Advanced режиме CMAKE
По умолчанию бы их для винды (всё равно же лежат рядом с проектом)… -
При компиляции не нашел zlib.h по указанному пути. Пришлось поменять в коде - прокатил просто “zlib.h”
Итоговые ошибки, которые я сам уже не смог исправить:
2>ThreadLoader.obj : error LNK2019: unresolved external symbol inflate referenced in function "public: virtual void __cdecl CThreadLoader::Start(class CThreadUnit * *,int)" (?Start@CThreadLoader@@UEAAXPEAPEAVCThreadUnit@@H@Z)
2>ThreadLoader.obj : error LNK2019: unresolved external symbol inflateEnd referenced in function "public: virtual void __cdecl CThreadLoader::Start(class CThreadUnit * *,int)" (?Start@CThreadLoader@@UEAAXPEAPEAVCThreadUnit@@H@Z)
2>ThreadLoader.obj : error LNK2019: unresolved external symbol inflateInit_ referenced in function "public: virtual void __cdecl CThreadLoader::Start(class CThreadUnit * *,int)" (?Start@CThreadLoader@@UEAAXPEAPEAVCThreadUnit@@H@Z)
(т.е. zlib он всё таки не зацепил. м.б. дело в 64бит? )
P.S. Натравил на скомпилированный вручную 64бит+vs2012 ZLIB (при неудачной попытке собрать OSRM по иструкции с сайта).
В итоге всё-таки собралось! Правда, не очень интуитивно понятно… Эксперты - как можно улучшить CMakeLists.txt ?
Что-то у меня было похожее с alacarte, zlib собирал с ключём Z_SOLO
Куль! Судя по описанию - почти никак не улучшишь. Библиотеки, включая boost, CMake ищет в тех местах, которые он считает “стандартными”, что на совести разработчиков соответветствующей поисковой примочки к библиотеке - поиском по всем дискам он не занимается. Так что тут поможет только дополнительное описание на случай что делать, если библиотеки установлены, но не “подхватились”. Add: при желании это можно в лог CMake’а добавить.
А вот zlib.h бы должен находить - странно.
Моё знакомство с Cmake состоялось на примере либы VTK от тех же авторов - там если ругается (например, на отсутствие QT), то появляется ещё один параметр -мол, “давайте мне каталог с Qt” (и комментарием в логе подтверждает).
zlib.h в коде был по хитрому относительному пути - наверное, на разных ОС/компиляторах он немного по разному по папкам ходит (или там большие/маленькие буквы). А что библиотека из комплекта несовместима - это просто не повезло
Хорошее замечание, припоминаю, что тоже такое видел, но сам - никогда не делал ))
“Хитрый-относительный” - это вряд ли правильный подход.
В общем, залез в код поиска QT в поисках примеров - оказалось, CMAKE не так уж ужасен (только чуть-чуть). Спасибо за подсказки! 
Сделал вариант, с более навязчивыми запросами BOOST_ROOT, ZLIB_* , попробуйте патч:
https://dl.dropboxusercontent.com/u/63393258/CMakeLists.txt.patch
Автору большой респект!
Кстати, а зачем мы PBF конвертируем в SQLITE? )))
Поскольку данные плохо лезут в память, а самим лениво заниматься эффективным ее распределением, то есть надежда, что за нас всё сделает дядя SQLITE.
Под linux от PCH лучше вообще отказаться. Во-первых, по сравнению с адекватной фильтрацией инклудов и использованием forward declarations они дают копеечный выигрыш, который вообще не будет заметен на таком небольшом проекте. Во-вторых, они мешают работе ccache и distcc, от которых пользы намного больше.
PS. Под фрю пока не собралось, там boost 1.52
Смотрю народ на работу вышел А то, подумал, никому не надо.
Отвечаю на предыдущие вопросы:
Для смаке мне нехватило следующих знаний - на заявленных платформах смаке умеет ТОЛЬКО настроить компилятор, для указанных исходников, И ВСЁ.
Я то грешным делом подумал что они(смаксисты) попытались объединить плюсы основных компиляторов/ide разных платформ. А на самом деле всё что смогли, так это предоставить маке файл и настроить ide на его использование.
Единственный плюс это язык позволяющий добавлять свои фишки для конкретных IDE/платформ. Но я не понимаю как в этом окружении обеспечивать рост знаний. Если я смог настроить смаке проект на два ide/платформы то это не значит что оно заработает на других платформах. Поэтому я никому не расскажу о моём опыте. Переход на 3 одновременно поддерживаемые платформы НЕВОЗМОЖЕН если нет чувака которые может проверить на всех трёх.
to akks спасибо за патч. Применил.
“Кстати, а зачем мы PBF конвертируем в SQLITE? )))” Отвечу вопросом на вопрос. А зачем, вообще, скачивать себе osm?
to “Ivan Komarov” - “Хитрый-относительный” - это вряд ли правильный подход.
Да, вы правы, была ошибка, непонятно как работало
to “AMDmi3” - Под linux от PCH лучше вообще отказаться…
хм. Я в общем то слаб в линукс. Но мне казалось что PCH уже давно должон был тут появится. Сборкой тут гораздо чаще занимаются чем под win.
gss -x тоже не новая опция. Ну и бог с ней. А вы поможете настроить смаке под ccache и distcc?
to “AMDmi3” - Под фрю пока не собралось, там boost 1.52.
Надо?. Если да. То как скоро? Может подождать до 1.53 на фрю? Иначе шлите мне ошибки компиляции будем думать вместе.
Нет, они сделали систему сборки, и пока лучшую. Компиляторы и IDE с системой сборки никак не связаны.
Да всегда был, собственно, только неудобен и никому не нужен.
Его не надо настраивать, нужно просто добавить в начало $PATH путь к директории с линками ccache и/или distcc.
Мне лично не надо, мне надо чтобы софт не писали под одну платформу
Лучше подождать 1.53.
Вы либо слишком молоды, либо не писали под Windows.
Посла появления в каждом модуле <windows.h> прекомпайл в умелых руках очень сильно облегчает жизнь.
Шаблоны, пока они в разумных дозах, тоже вполне укрощаются прекомпайлом и на линукс.
Ну а для тех, кто пишет в нынешнем новомодном стиле всю программу шаблонами в хедер-файлах, цепляя как можно больше кривовато написанных сторонних “свободных” библиотек, действительно возможно другие методы будут эффективнее.
Ещё проблема: на конфигурации древний RedHat + вручную собранные gcc4.7.2, zlib, bzip2, boost 1.53 (наш кластер)
после успешного уговаривания Cmake, make выдаёт следующую ошибку компиляции:
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/PBFRO/PbfFBytes.h:44:19: warning: no newline at end of file
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/OSMPBF/../PBFRO/TFuint.h:182:20: warning: no newline at end of file
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/OSMPBF/../PBFRO/TFsint.h:58:20: warning: no newline at end of file
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp: In member function `boost::filesystem::path CDB::GetFileNameOut() const':
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:84: error: no matching function for call to `boost::filesystem::path::assign(const char* const&, char*)'
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:207: note: candidates are: boost::filesystem::path& boost::filesystem::path::assign(const char*, const std::codecvt<wchar_t, char, mbstate_t>&)
make[2]: *** [OsmPbf2sqlite/CMakeFiles/OsmPbf2sqlite.dir/DB.cpp.o] Error 1
Это в Boost чего-то не хватает или как?
Угу вторые аргументы у функций не совпали.