Объясните популярно, что такое "Clang"
PoLiNoMm 6 февраля, 2010 - 23:52
Никак не могу понять, что это такое?
С чем его едят и для чего?
»
- Для комментирования войдите или зарегистрируйтесь
http://ru.wikipedia.org/wiki/
http://ru.wikipedia.org/wiki/CFLAGS
http://en.gentoo-wiki.com/wiki/Safe_Cflags
http://en.gentoo-wiki.com/wiki/Safe_Cflags/Intel
http://en.gentoo-wiki.com/wiki/CFLAGS
http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD
думаю станет многое понятно... слишком обширный вопрос )
Товарищ как бы не о том
Товарищ как бы не о том спрашивает...
:}
.
Clang + LLVM позволяют компилировать программы на C, C++ и Objective-C
Цель создания - уйти от GCC тем, кому это надо.
http://clang.llvm.org/
http://blog.llvm.org/
http://www.llvm.org/
http://video.google.com/videoplay?docid=1921156852099786640# - c 18:55
Это подпись, которую невозможно истолковать неправильно
хм.. а чем GCC плох, что
хм.. а чем GCC плох, что отнего надо уходить? я как понял лицензия может дать только ограничения?
.
по последней ссылке, с 18:55 начинают отвечать на ваш вопрос.
Говорят там примерно следующее:
1) gcc, нехороший такой, не удовлетворяет нуждам IDE от Apple
2) gcc, шибко оптимизирующий такой, не сохраняет некоторую полезную информацию
3) gcc, сложный такой. IDE-писателям трудно изучить gcc + его реализация и полиси затрудняют внесение изменений.
4) gcc кушает память и работает очень медленно.
правда... это ответы 2007 года.
Так что... ждём от них свежих видео :)
P.S. лицензия? я не уверен, что на ЭТОМ сайте стоит эту тему продолжать. Холиварить и троллить есть много мест, давайте gentoo.ru от этого ограждать?
Это подпись, которую невозможно истолковать неправильно
>правда... это ответы 2007
>правда... это ответы 2007 года
ага, то есть сравнивается gcc 4.2 и llvm-gcc 4.2
А у нас сейчас stable 4.3.4, unstable 4.4.3, и development 4.5. Так что, по идее, корректно надо бы сравнивать gcc 4.5-svn и dragonegg llvm в виде плагина к этому gcc 4.5.
Ну, и конечно подождать с бенчмарками пока gcc 4.5 стабилизируется, или в clang C++ допилят.
Спасибо за обмен этой
Спасибо за обмен этой должности. Это очень полезные и информативные материалы. Хороший пост и сохранить его. Сайты всегда полезны в той или с другой стороны, это удивительные вещи, В любом случае, это хороший способ начать отремонтировать свою мечту в мире reality.I напишем более подробно после моей mba в ближайшее время. Спасибо!
>хм.. а чем GCC плох, что
>хм.. а чем GCC плох, что отнего надо уходить?
кроме видео, на сайте проекта есть PDF и презентации про то, зачем понадобился новый компилятор и в чём проблемы с GCC: старая кодовая база, которую сложно изменить; громоздкий, неудобный AST, который теряет полную информацию об разбираемом месте в процессе трансформаций и оптимизаций (в итоге, сложно отследить, какому элементу исходника соответствует преобразованный кусок); сложность подключения новых плагинов, бекендов (хотя в gcc 4.5 в SVN ведётся работа над "плагинизацией" GCC) -- в llvm компилятор, оптимизатор, кодогенератор, фронтенд/бекенд это просто загружаемые библиотеки; более простой и понятный вид AST (сравни написание своего плагина/фронтенда для GCC и для LLVM (см например в публикациях про 3c python -- бейсик на питоне через llvm, и сравни его с аналогичными доками для gcc по GIMPLE/GENERIC/RTL)
Плюс, как бы сама основная идея LLVM: придумать виртуальную машину, близкую к железу, к возможностям оптимизации. Поверх LLVM потом планировалось накрутить HLVM, но там что-то проект в SVN заглох.
Ну и остальные публикации -- тоже весьма интересные встречаются. Например, практические применения -- Adobe, Apple, FreeBSD :)
Лицензия, да. Вот тут есть засада, в GCC и GPL -- на тему GPL derived work.
Собственно, GCC в качестве универсального кодогенератора не очень удобен по 3 причинам:
1) старая кодовая база, в которой ч0ртъ ногу сломит -- сложно добавить новые плагины/фронтенды/оптимизации -- хотя в 4.5 уже получше
2) довольно монолитная структура самого gcc; -- тот же libgcc/libstdc++
3) лицензия GPL, что не позволяет его использовать в качестве кодогенератора в своем приложении -- нужно открывать исходники приложения
4) громоздкость в целом.
проблем с реальным использованием clang я вижу две:
1. неполная поддержка c++
2. неполная поддержка gcc расширений -- например, ядро FreeBSD и ядро DragonflyBSD собираются clang-ом, а Linux пока ещё много имеет gcc-измов.
3) лицензия GPL, что не
Сфигасе это, "лоровский аналитег" что ли ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Цитата: 3) лицензия GPL, что
Конечно, таким же макаром можно запретить K3b жечь диски с closed-source софтом. Травкой не поделитесь?
Гость написал(а): Ну и
...и на десятый год разработки оно таки сумело сделать bootstrap. Ну а дальше посмотрим, через сколько лет у clang появится нормальная генерация под atmel (8 и 32 бита), все виды arm, mips etc.
1-> 2-> 3-> 4-> ...по трем причинам.
Нас удостоил вниманием "онолитег ЛОРа"?
P.S. а вот такое у него имеется? :)
Пожелания GCC
Уже была идея придумать кросс-платформенный ассемблер, который бы конвертился в исполняемый код любого существующего на планете процессора. Так появился язык С. :-)
Во-первых, со временем напишут новую. В опенсорсе не обязательно заморачиваться полной совместимостью с продуктами тыща девятьсот лохматого года релиза.
Во-вторых, поддержка новых архитектур и таржетов добавляется регулярно, языков программирования тоже понасовали сколько могли, хотя большинству достаточно C, C++, Java.
Которая волнует только девелоперов этого самого gcc. Остальным достаточно, чтобы он код генерил правильно. Конечно, можно из него сделать монстра, обвешанного побрякушками, по принципу «из любого языка программирования -- в исполняемый код любого на планете процессора/контроллера», но ЗАЧЕМ? Пусть gcc остаётся gcc, а clang -- clang'ом. Когда есть альтернатива -- это нормально. gcc может прочно занять нишу компилятора для системного и встраиваемого ПО, clang -- для сложного прикладного.
Это вообще бред собачий. Полно коммерческих рабочих сред для разработки ПО для микроконтроллеров, где генерацией кода занимается именно gcc.
Мои пожелания gcc:
1) Чтобы он не разбрасывал свои компонены по всей файловой системе. Особенно это проявляется при сборке кроссового компилятора(-ов).
1а) Чтобы можно было внятно задать спеки при сборке. Сказать ему, где искать инклюды, где -- библиотеки, а куда ставить свои приблуды. Уже надоело, что в списке путей у него вечно феерический бред вроде /usr/lib/gcc-lib/4.4.x/../../../lib/, сколько можно наблюдать это непотребство.
2) Чтобы он мог генерировать стандартизированные сообщения об ошибках, чтобы облегчить написание к нему GUI и встраивание в интегрированные среды разработки.
the Aquihost Rigorous Builder