Clang і llvm: передісторія

Відео: Rebuilding Debian with LLVM / Clang - Sylvestre Ledru, Debian / IRILL

У світі UNIX-подібних систем стандартом де-факто став GCC. Складно уявити собі, що можна для практичних потреб, для складання програм на C / C ++ використовувати щось інше. У світі вільного ПЗ та ПЗ з відкритим кодом придатність компілятора для роботи визначається його здатністю збирати з вихідного коду якомога більшу кількість програм. Якщо компілятор, навіть надшвидкий і підтримує но-Веші технології, вміє компілювати одну-дві програми, в інтересах, скажімо, певної компанії або якогось співтовариства, це не означає, що цей компілятор - «заміна» більш поширеній. Альтернативи виникають, коли якийсь продукт стає з яких-небудь причин незручним групі користувачів. Кому і чому став незручний GCC, і що стало причиною виникнення Clang?


Компанія Apple використовувала в своїх розробках LLVM і фронтенд від GCC. Власне, спочатку LVVM був створений в 2000 році без підтримки Apple, але в 2005 році Apple найняла для його розробки на постійній основі цілу команду. Отже, LLVM функціонував в зв`язці з GCC. Але GCC, як відомо, орієнтований на Сі і С ++, в той час як Apple була потрібна хороша підтримка Objective C. Крім того, всередині «групи LLVM» визнали, що GCC занадто громіздкий, та до того ж погано стикується з IDE від Apple. І навіть це ще не все: GCC ліцензований під GPL, а згідно GPL розробники зобов`язані відкривати код своїх доповнень до компілятору, в той час як, припустимо, в BSD-подібних ліцензіях це не потрібно.








Так і виник компілятор Clang, код якого був відкритий в 2007 році під ліцензією University of Illinois / NCSA Open Source License. В мережі (https://llvm.org/devmtg/2007-05/09-Naroff-CFE.pdf) лежать слайди для минулого тоді зборів розробників LLVM. На слайдах великими написами виражається необхідність в новому фронтендів. Виражається і «мотивація», чому не підходить GCC. «Крива вивчення занадто складна для багатьох розробників» (зауважу, що крім кривих вивчення, можна рухатися по прямій), «політика обмежує інновацію» і так далі. Наводяться приклади, як Clang і GCC по-різному повідомляють про помилки - мовляв, Clang зрозуміліше. Даються графіки швидкості роботи на прикладі, як відбувається компіляція carbon.h (API на Сі для Mac OS X- на той час - вихідні розміром в 12,3 Мб) - справді, Clang в 2,5 рази швидше впорався з цим. Власне, ніхто ніколи не штрафував GCC за перевищення швидкості. Навіщо це ставити в докір? Нещодавно, 29 жовтня цього року, в колишньому Trolltech зібрали Qt повністю на Clang, і ось порівняльні графіки з GCC: https://labs.qt.nokia.com/2010/10/29/compiling-qt-with-clang. При цьому у Clang розміри бінарників під Mac виявилися меншими, ніж зібрані в GCC, а під Linux навпаки - GCC зробив меншими бінарних-ки. Крім того, отримані за допомогою Clang бінарники виявилися на 16% повільніше під Linux і на 6 - під Mac. Що важливіше користувачеві: швидкість компіляції або швидкість роботи вже зібраної програми?

У тому ж жовтні за допомогою Clang зібрали і щодо робоче ядро Linux (https://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html). У мережі час від часу з`являються радість-ні повідомлення про те, що під Clang тепер збираються то бібліотека Boost C ++, то HelenOS. Бродять думки про те, щоб Clang зробити основним компілятором для збірки FreeBSD. Добре б ще виникла ідея зробити дизайн сайту Clang (http: // clang. Llvm.org) робочим, а то меню зліва у мене на екрані поміщається в повному обсязі і при цьому не прокручується, а іноді і зовсім заважає перегляду матеріалів, перекриваючи їх. ..

---

Набагато більше, ніж система аналізу, трансформації та оптимізації програм LLVM, Вас цікавить будівельне обладнання (https://tehnofond.ru) найвищої якості? Тоді я настійно раджу Вам звернутися до фахівців компанії "Технофонд". Тільки тут Ви зможете придбати все необхідне Вам обладнання за максимально вигідною для себе ціною!