Первое что бросается в глаза собранный clang чудовищно тормозит, и это при релизной сборке! Даже простейший «clang++ --version» может выполнятся несколько секунд. Решение простое: нужно собирать его со статической линковкой, тогда все работает быстро, но ценой увеличенного размера бинарников (десятки мегабайт).
Исправляем проблемыСкорость работы
Создаем новый каталог для компиляции, снова запускаем там ../configure и затем make. Но clang не соберется самим собой так просто, иначе в чем был бы смысл этой статьи?
export CC=/newclang/bin/clang.exe
export CXX=/newclang/bin/clang++.exe
Далее самосборка. Она нужна чтобы убедиться, что компилятор работает надежно, мы не упустили каких-либо проблем, и чтобы устранить одну переменную: «версия ксенокомпилятора». Перключаем систему на использование только что собранного clang для дальнейшей сборки им самого себя:
После завершения конфигурации пишем make, и начнется сборка проекта. Когда закончится make можем сделать make install, и наши скомпилированные бинарники запишутся в каталог newclang в корне файловой системы MSYS.
../configure --disable-docs --enable-optimized --enable-targets=x86 --prefix=/newclang
После этого создаем каталог для бинарников, например llvm/bin, переходим туда, и выполняем команду:
Запускаем консоль MSYS, качаем исходники llvm, clang, compiler-rt (низкоуровневый системный код для сборки), распаковываем llvm в корень вашей папки с исходниками, clang в llvm/tools, compiler-rt в llvm/projects. Проверяем версию gcc для llvm 3.2 подойдет gcc не новее 4.6.2 (с 4.7.2 у меня он сам себя не смог собрать, но и слишком старый тоже нельзя).
MSYS дает нам «linux» shell, в котором можно запускать стандартные билд-скрипты. Именно по этому пути мы и пойдем.
Mingw32+MSYS. содержит gcc и тонкую обертку, реализующую linux-подобное окружение для программ, трансляцию путей windows<>linux style. Специфичные функции (вроде fork) полностью не реализованы, потому совместимость хуже чем у cygwin, но работает все быстрее. Частичное описание процесса сборки .
CMake позволяет сгенерировать solution для Visual Studio. clang+llvm до сих пор зависит от компонент gcc (стандартной библиотеки например, но работа над устранением зависимости идет), потому даже собирая clang в Visual Studio эта зависимость останется, и у вас получится дичайшая солянка из кусков clang, VS и gcc, где все компоненты со временем будут случайно менять версии. Помимо этого, на данный момент Visual Studio 2012 падает при сборке clang 3.2 с оптимизацией Microsoft работает над фиксом (в 2010 все ок). В свете этого, я решил Visual Studio не использовать, тем более на конечный результат (clang собранный clang) это не должно особо повлиять.
СборкаСуществуют 2 основных способа собирать llvm+clang под windows:
БОльшая часть часть разработчиков llvm/clang используют его под Linux/MacOS и там его сборка/установка не вызывает каких либо проблем, путь основательно протоптан. А вот в случае windows ситуация несколько осложняется об обходе нескольких граблей при сборке, о том, что связывает clang и gcc, и какие баги придется фиксить в релизе под катом.
С LLVM+CLang будет интересно поиграть любому кто когда-либо хотел написать свой компилятор, или считает, что компилятор собранный своими руками дает более теплый бинарный код.
Помимо этого, Clang и llvm распространяются под лицензией BSD, в отличии от GPLv3 у GCC. BSD позволяет не открывать исходники при распространении исполняемых файлов.
LLVM это набор «кирпичиков» для построения компиляторов, а clang новый компилятор C++ на его основе. По сравнению с gcc обеспечивается большая скорость компиляции при сравнимом качестве кода, более человеко-понятные исходники т.к. они не несут десятилетия жесточайшей C-only разработки как в gcc.
LLVM+Clang 3.2: собираем самим собой под Windows
LLVM+Clang 3.2: собираем самим собой под Windows / Хабрахабр
Комментариев нет:
Отправить комментарий