Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 67
> Open source software — это узкая протоптанная тропинка в дремучем лесу.
Я не понимаю при чём тут опенсорсность. Была бы это программа с закрытыми исходными кодами — что было бы по-другому? (Подсказываю: были бы бинарники под поддерживаемые платформы и всё, точка.)
Насчёт релиза — это просто чуть более протестированная версия, чем trunk. Но фиксов после заморозки в релиз обычно входит очень мало — очень мало заинтересованных. Все заинтересованные сидят на SVN версии. Поэтому могу посоветовать тоже брать версию из SVN.
И ещё нет самого важного — прогона тестов. Без прогона тестов можно собрать всё что угодно, но не компилятор. make check-all.
> Проверяем версию gcc — для llvm 3.2 подойдет gcc не новее 4.6.2 (с 4.7.2 у меня он сам себя не смог собрать, но и слишком старый тоже нельзя).
Это какая-то Windows-специфичная проблема (?). Зарепортите баг? Под Debian gcc 4.7.2 собирает нормально.
Я не понимаю при чём тут опенсорсность. Была бы это программа с закрытыми исходными кодами — что было бы по-другому? (Подсказываю: были бы бинарники под поддерживаемые платформы и всё, точка.)
Насчёт релиза — это просто чуть более протестированная версия, чем trunk. Но фиксов после заморозки в релиз обычно входит очень мало — очень мало заинтересованных. Все заинтересованные сидят на SVN версии. Поэтому могу посоветовать тоже брать версию из SVN.
И ещё нет самого важного — прогона тестов. Без прогона тестов можно собрать всё что угодно, но не компилятор. make check-all.
> Проверяем версию gcc — для llvm 3.2 подойдет gcc не новее 4.6.2 (с 4.7.2 у меня он сам себя не смог собрать, но и слишком старый тоже нельзя).
Это какая-то Windows-специфичная проблема (?). Зарепортите баг? Под Debian gcc 4.7.2 собирает нормально.
К сожалению, после падения компилятора VS дальше сильно в эту сторону не копал, тем более что моя конечная цель была — в любом случае собирать clang самим собой.
MSVC ABI немного умеет, но поддержка очнеь неполная. Стандартную библиотеку C++ от MS использовать, IIRC, нельзя.
Исключения на Windows — не знаю, зайдите в IRC спросите.
Кросс-компилировать — да. Clang — это принципиально кросс-компилятор, ему вообще всё равно какой у вас хост. Просто дефолтный таргет драйвером выставляется в хост, если есть соответствующий бекенд.
Исключения на Windows — не знаю, зайдите в IRC спросите.
Кросс-компилировать — да. Clang — это принципиально кросс-компилятор, ему вообще всё равно какой у вас хост. Просто дефолтный таргет драйвером выставляется в хост, если есть соответствующий бекенд.
Кхе-кхе, вы уверены на счёт кросс-компиляции между разными ОС? Компилятору-то, может и пофиг какой ABI генерить, но нужны тулы операционной системы для некоторых операций — например для мандлинга (c++filt на линуксе, хотя он используется не напрямую, а через библиотеки) и линковки (ld соответственно).
Clang'у не нужен c++filt для манглинга, он вообще никому кроме пользователей для чтения дампов не нужен.
Для линковки — да, нужен подходящий ld. Но это для линковки. А для компиляции — нет.
Для линковки — да, нужен подходящий ld. Но это для линковки. А для компиляции — нет.
С поддержкой виндовых исключений пока вроде никак. И вцелом поддержка винды хромает — она просто не нужна никому из тех, кто контрибьютит в llvm профессионально (по сути это сотрудники Apple и Google и некоторых HPC-ориентированных организаций). Хотя всячески приветствуется меинтейнерами.
Работа над MSVC ABI ведётся, можете посмотреть мои последние коммиты и патчи :)
Проблема многопоточной сборки для меня решилась использованием cmake с генерацией мейкфайлов для ninja, и сборкой, соответственно, через ninja. После этого пропали все проблемы с зависанием.
Вообще, ninja оказалось очень крутой штукой. Перекомпиляция при правке кода быстрее, чем у make, например, очень советую.
Вообще, ninja оказалось очень крутой штукой. Перекомпиляция при правке кода быстрее, чем у make, например, очень советую.
Увы, на Windows перекомпиляция при правке небольших изменений упирается в… linker*.
Который, увы, ninja использует стандартный.
* — во всяком случае, на Clang.
Который, увы, ninja использует стандартный.
* — во всяком случае, на Clang.
Не знаю что там конкретно с ниндзями и шлангом, но виндовы линкер поддерживает инкрементальную линковку, поэтому не должно упираться. Этим виндовый линкер оказывается сильно круче гнутого в некоторых usage cases.
У меня под винды incremental включён, при этом (кажется) гораздо медленнее чем многопоточный gold на Linux.
К тому же увы incremental linker весьма нестабилен на больших проектах…
К тому же увы incremental linker весьма нестабилен на больших проектах…
Странно, в 3.1 версии не было проблем с visual studio, собирал cmake с buildtype release и nmake.
Тогда наверное 2012-й студии не было. В более старых версиях студии по идее все ок.
Жду когда-же clang будет доступен без mingw для windows официально. Пока пробовал к CodeBlocks подключить существующую экспериментальную сборку для mingw.
Надеюсь, что появятся плагины для Visual Studio, Qt Creator и других сред разработки…
Надеюсь, что появятся плагины для Visual Studio, Qt Creator и других сред разработки…
Вообще говоря, для компилятора BSD-лицензия вместо GPL — это не преимущество, т.к. потенциально может привести к десятку разных несовместимых компиляторов на его основе, как когда-то было с X-серверами. Некоторые разработчики Embedded-компиляторов и с GCC далеко не всегда полностью лицензию соблюдают, а о clang они, видимо, не в курсе ещё.
Можно взглянуть на это со стороны компаний, инвестирующих в компиляторы для своей платформы или для каких-то своих нужд. И они хотят иногда делать проприетарные вещи, что вполне логично и правильно. Другое дело, что проприетарные компиляторы не получают большого распространения по вполне понятным причинам.
Лучше инвестировать в большой общий компилятор, тем более, что они от этого ничего не потеряют, а только выиграют — апстримовые майнтейнеры будут более или менее их код поддерживать даже в минимальном случае, а с большой вероятностью — если платформа станет популярной — то и принимать активное участие в разработке. А для внутренних наколенных поделок любая лицензия проблемой не является.
Большие компании параноидальны по поводу лицензий (собственно, это не случайно). Поэтому даже для внутренних разработок это проблема.
В llvm общие патчи идут в транк, но логично, что компании хотят иногда иметь свои версии, с блекджеком и пианистками. Причины могут быть очень разные — начиная от того, что хочется делать апдейты для кастомеров быстрее, чем позволяет цикл фиксов в опен сорсе (который может зависть от скорости ревью сообществом, который непредсказуем в общем случае), до того, что хочется делать фиксы, которые не могут быть приняты сообществом по политическим соображениям. Вот, например, хочет компания Х запилить в компиляторе поддержку какой-то технологии Y (проприетарной или нет, не важно), а сообщество им говорит — идите в пень, там не интересно. Или говорят, ваша технология конечно интересная, но давайте вы пропихнёте её хотя бы до стадии драфта в С++ комитете, тогда и поговорим. Замечу, что это не теоретические, а очень даже практические соображения с вполне конкретными примерами.
Плюс, очень важный момент в том, что GPL v3 налагает очень серьёзные требования к правам на интеллектуальную собственность. Если компания закоммитила патч в GPLv3 проект и там был код коррелирующий с каким-то патентом компании, то она лишается этого патента. Здесь понятен интерес опен сорс сообщества, но компании счастья по этому поводу не испытывают и шарахаются от таких проектов, как чёрт от ладана.
В llvm общие патчи идут в транк, но логично, что компании хотят иногда иметь свои версии, с блекджеком и пианистками. Причины могут быть очень разные — начиная от того, что хочется делать апдейты для кастомеров быстрее, чем позволяет цикл фиксов в опен сорсе (который может зависть от скорости ревью сообществом, который непредсказуем в общем случае), до того, что хочется делать фиксы, которые не могут быть приняты сообществом по политическим соображениям. Вот, например, хочет компания Х запилить в компиляторе поддержку какой-то технологии Y (проприетарной или нет, не важно), а сообщество им говорит — идите в пень, там не интересно. Или говорят, ваша технология конечно интересная, но давайте вы пропихнёте её хотя бы до стадии драфта в С++ комитете, тогда и поговорим. Замечу, что это не теоретические, а очень даже практические соображения с вполне конкретными примерами.
Плюс, очень важный момент в том, что GPL v3 налагает очень серьёзные требования к правам на интеллектуальную собственность. Если компания закоммитила патч в GPLv3 проект и там был код коррелирующий с каким-то патентом компании, то она лишается этого патента. Здесь понятен интерес опен сорс сообщества, но компании счастья по этому поводу не испытывают и шарахаются от таких проектов, как чёрт от ладана.
Пожалуйста, не надо говорить о том, насчёт чего Вы не вполне в курсе. Авторские права никак не коррелируют с патентами. Если апстрим GCC или кого угодно не хочет принимать патчи в таком виде, в котором они есть, ничто не мешает их развивать отдельно, как делала Apple. Для этого совсем не обязательно прятать исходники.
С патентами, конечно, сложности. В идеале хорошо бы иметь лицензию, которая была бы не такая экстремистская как GPLv3 по отношению к владельцам патентов и при этом защищала бы опен сорс нормально. Иначе компании просто всеми средствами избегают GPLv3, что тоже не очень хорошо для всеобщего прогресса.
Вообще-то я говорю о том, о чём я вполне осведомлён. Хотя, конечно, всё равно могу ошибаться. Вот цитата из Википедии про GPLv3:
According to Stallman, the most important changes are in relation to software patents, free software license compatibility, the definition of «source code», and hardware restrictions on software modification («tivoization»).
У меня сейчас нет под рукой ссылок, но насколько я помню, это сформулировано так, что патенты в случае их использования правообладателями в GPLv3 коде отходят в public domain.
According to Stallman, the most important changes are in relation to software patents, free software license compatibility, the definition of «source code», and hardware restrictions on software modification («tivoization»).
У меня сейчас нет под рукой ссылок, но насколько я помню, это сформулировано так, что патенты в случае их использования правообладателями в GPLv3 коде отходят в public domain.
Так llvm+clang же и появился вроде из-за того, что Apple не смогла работать с GPL-нутым GCC, они хотели часть своего кода закрытым оставить.
Не не смогла, а не захотела. И, насколько я знаю, дело было не в закрытом коде, а в том, что просто не договорились. Не помню точно, но вроде как Apple тупо развивала свой форк и не пыталась эти патчи послать по всем правилам в апстрим.
Ну это вопрос технический, на самом деле, и решаемый, если хотеть.
Это вопрос технический, но нерешаемый. Внутренности GCC — это помойка by design, которая была создана в таком виде специально и злонамеренно. Столман заявлял, что они специально делали GCC таким образом, что никакие его части не могли бы быть переиспользованы где-либо ещё.
Пожалуйста, не надо говорить глупости.
Ээээ. Вам линк на Столмана дать?
Вы имели счастье иметь дело с внутренностями llvm и gcc?
Вы имели счастье иметь дело с внутренностями llvm и gcc?
Немного ковырял, не нашёл ничего такого страшного. А линк дайте, пожалуйста, интересно.
На самом деле, я не защищаю Столлмана, он часто фигню несёт :) Когда-то он облил помоями Tcl, чего я ему до сих пор простить не могу, например :)
На самом деле, я не защищаю Столлмана, он часто фигню несёт :) Когда-то он облил помоями Tcl, чего я ему до сих пор простить не могу, например :)
На http://gcc.gnu.org/wiki/cauldron2012 есть ссылка на http://kam.mff.cuni.cz/~hubicka/rms/rms.html, где как раз само видео. Там он говорит про то, что я сказал на 25:17. Но у меня сейчас почему-то ссылка нормально не открывается. Там ещё есть ссылка для скачивания видео в формате OGG Video, можно её попробовать.
О технической стороне дела — медицинский факт, что gcc изначально спроектирована так, чтобы препятствовать переиспользованию его кода, llvm же изначально ориентирован на модульную структуру и доступность функциональности через API.
Одна только история с тем, как долго пытались продраться меинтейнеры gcc сквозь технические сложности перед тем, как смогли добавить возможность межпроцедурных оптимизаций (LTO в терминах gcc), говорит о том, как там всё запущено.
Одна только история с тем, как долго пытались продраться меинтейнеры gcc сквозь технические сложности перед тем, как смогли добавить возможность межпроцедурных оптимизаций (LTO в терминах gcc), говорит о том, как там всё запущено.
Вот статья с мнениями нескольких маинтеинеров gcc о том, почему это технически невозможно (а также о том, почему, по их мнению, жить gcc осталось недолго).
I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: «toolability» (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications.
That is a need that g++ cannot currently satisfy. With plugins, one could do something along those lines, but they are heavier, and are at the mercy of the full compiler. Additionally, g++ has very low fidelity wrt the input program; it breaks down the original C++ input almost immediately.
А не могли бы подсказать существует ли готовый набор для Windows?
На сайте llvm можно скачать сразу собранный в mingw32 «эксперементальный» билд 3.2, работет.
llvm.org/releases/3.2/clang+llvm-3.2-x86-mingw32-EXPERIMENTAL.tar.gz
К нему нужны будет еще dll-ки PThreads еще скачать.
llvm.org/releases/3.2/clang+llvm-3.2-x86-mingw32-EXPERIMENTAL.tar.gz
К нему нужны будет еще dll-ки PThreads еще скачать.
BSD позволяет не открывать исходники при распространении исполняемых файлов.
Можно узнать откуда вы это взяли? В GCC используется дополнительное разрешение в соответствии со статьей 7, т.е. вы можете спокойно собирать программы под любой лицензией (в том числе под собственнической) с помощью GCC с использованием библиотек входящих в GCC, таких как libstd++, libquadmath и т. д.
Речь идет об исходниках и исполняемых файлах самого компилятора. Вот обсуждение замены gcc на clang/llvm в FreeBSD: «The primary reason for switching from GCC to Clang is the incompatibility of GCC's GPL v3 license with the goals of the FreeBSD project.» У Apple тоже были проблемы из-за GPLv3: [1], [2]: «GCC. One is that it is delivered under the GPL, which means Apple can't integrate it directly into Xcode without making its IDE GPL as well. Apple prefers BSD/MIT style open source licensees, where there is no limitation upon extending open projects as part of larger proprietary products.», [3] «Apple… The notoriously GPL-averse company has wanted to move away from using GCC for some time, and the BSD-ish licensed LLVM is the path that it has chosen. It is more than just a licensing issue, though, as LLVM has some technical advantages as well. But it is thought that GCC's move to GPLv3, with its more explicit patent provisions and anti-Tivo-ization language, has made the GCC to LLVM move that much more important to Apple. „
В данной статье, в данном предложении было сказано о исполняемых файлах (т.е. о результате компиляции) и ни о чем более. Поэтому ваше цитирование ни играет ни какой роли к моему сообщению, т.к.:
В итоге тот факт, что GCC можно собирать программы с любой лицензией и не открывать исходные коды остается на месте, и ошибка в статье тоже.
- Господа из FreeBSD переходят на Clang из-за их «религиозных верований» (что вы и процитировали). К примеру господам из DragonFlyBSD все равно, поэтому они перешли на GCC 4.4 (а в версии 3.4 на GCC 4.7).
- Apple просто напросто нужно брать, но не отдавать, т.к. им у них куча патентов, всевозможная тивоизация и другие ограничения, которые GPLv3 не позволяет, вот они и хотят подстраховаться. Да и им проще будет, т.к. в MacOS X тот-же OGL через LLVM работает
В итоге тот факт, что GCC можно собирать программы с любой лицензией и не открывать исходные коды остается на месте, и ошибка в статье тоже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
LLVM+Clang 3.2: собираем самим собой под Windows