Сильвестр Ледрю (Sylvestre Ledru) провёл (http://sylvestre.ledru.info/blog/sylvestre/2012/02/29/rebuil...) эксперимент по пересборке архива пакетов Debian GNU/Linux с использованием компилятора Clang (http://clang.llvm.org/), развиваемого в рамках проекта LLVM. Целью эксперимента была оценка пригодности Clang для сборки большого числа разнородного кода на языках C, C++ и Objective-C. Таким образом планировалось оценить, сможет ли Clang на текущей стадии развития выступать в роли альтернативы GCC при сборке пакетов в Debian. Интерес также представляли расширенные возможности Clang по выводу информации о возможных ошибках и недоработках, учёт которых позволил бы повысить общее качество кодовой базы.
Результаты эксперимента (http://clang.debian.net/) превзошли ожидания, из 15658 пакетов проблемы со сборкой в Clang 3.0 были выявлены только для 1381 пакетов (8.8 %), что соизмеримо (http://www.opennet.me/opennews/art.shtml?num=7257) с числом проблем, возникавших в прошлом при переходе на более новые ветки GCC. Сильвестр Ледрю признался, что ожидал столкнуться с большим числом ошибок и проблем, связанных с Clang, но к своему удивлению обнаружил, что большинство проблем сборки оказались связаны с разницей в поддерживаемых стандартах языка Си, различиями в интерпретации или спорными моментами. В итоге, Сильвестр сделал вывод, что Clang уже достаточно стабилен и функционален для сборки большинства пакетов Debian, даже если для многих пакетов потребуются небольшие правки для обеспечения корректной компиляции. Из наиболее часто встречающихся проблем сборки в Clang 3.0 отмечены: отсутствие необходимых символов на этапе связывания (439 пакетов), неверный поиск в шаблонах классов (85) и сбой в работе сборочной утилиты xutils-dev (84).
Для сравнения была предпринята попытка пересборки с использованием прошлой версии Clang - 2.9. В результате был отмечен значительный прогресс в развитии Clang, версий 2.9 не удалось собрать 14.5% пакетов, в то время как для версии 3.0 несобранными остались только 8.8%. Кроме того, отмечаются такие достижения Clang, как обеспечение пересборки Chromium/Chrome, LibreOffice, замена gcc на clang в базовой системе FreeBSD, а также решение компании Apple по использованию Clang по умолчанию в Xcode, инструментарии разработки приложений для Mac OS X и iOS.
Судя по всему в следующие несколько лет, обладая лучшими средствами для статического анализа кода, Clang может заменить gcc/g++ в качестве компилятора C/C++ во некоторых дистрибутивах Linux и BSD-системах. Тем не менее, в обозримом будущем GCC останется основным компилятором Debian, так как одним из основных требований проекта является обеспечение надлежащей поддержки всех архитектур Debian, который насчитывается 11 официальных и 6 неофициальных. К сожалению Clang в полной мере пока поддерживает только архитектуры X86-32, X86-64 и ARM.
URL: http://sylvestre.ledru.info/blog/sylvestre/2012/02/29/rebuil...
Новость: http://www.opennet.me/opennews/art.shtml?num=33281
> К сожалению Clang в полной мере пока поддерживает только архитектуры X86-32, X86-64 и ARM.Так эпплу больше ничего и не надо - у них другие процессоры не используются...
А при чём здесь Apple? Clang как и LLVM свободные проекты.
Ну скажем так, условно свободные или как-бы свобоные (пока). Apple эти проекты ужинает, значит и танцует. Apple, как мы знаем, матёрый проприераст.
Вот на свободе CUPS эпплосвобода уже начала сказываться.
> Вот на свободе CUPS эпплосвобода уже начала сказываться.А в чем начались проблемы у КУПСа после покупки его яблоком?
> А в чем начались проблемы у КУПСа после покупки его яблоком?bonjour оставлен как единственное средство поиска очередей.
не надо врать.
оставлен ZeroConf - который весь из себя RFC.
в отличии от самопала имени CUPS.
Так тчо правильной дорогой идут - стандартизируют вместо виласипедов.
> не надо врать.
> оставлен ZeroConf - который весь из себя RFC.
> в отличии от самопала имени CUPS.По сути bonjour не сильно отличается от zeroconf/avahi. Проблема в том, что раньше это работало, а теперь не будет, пока не поставишь avahi. А он изредка весело глючит.
> Так тчо правильной дорогой идут - стандартизируют вместо виласипедов.
ага, выпилили велосипед имени CUPS, а свой (bonjour) запилили. Уж если все-таки велосипеды оставляют, а не выпиливают во имя стандартов, то почему бы CUPS'овские не оставить?
> По сути bonjour не сильно отличается от zeroconf/avahi. Проблема в том, что раньше это работало, а теперь не будет, пока не поставишь avahi. А он изредка весело глючит.для чукчей который писатели, а не читатели. Bobjour - это реализация ZeroConf и RFC 2606 в частности - работающая на MacOS.
http://en.wikipedia.org/wiki/Zero_configuration_networking> ага, выпилили велосипед имени CUPS, а свой (bonjour) запилили. Уж если все-таки велосипеды оставляют, а не выпиливают во имя стандартов, то почему бы CUPS'овские не оставить?
Еще раз для чукчей которые не разбираются в теме.
CPUS не стандарт не капли. а RFC 2606 вполне себе стандарт, реализацию которого в CUPS впилили.
Казалось бы стоило радоваться что все стандартизировано - ан нет. чукчи-ретрограды тянут все назад.
Таково было решение разработчиков. То есть, если бы ими были не Apple, возмущения от аналогичного решения не было бы, так что ли?
> Ну скажем так, условно свободные или как-бы свобоные (пока). Apple эти проекты
> ужинает, значит и танцует. Apple, как мы знаем, матёрый проприераст.
> Вот на свободе CUPS эпплосвобода уже начала сказываться.Как этот CUPS задолбал, в каждый дистриб суют эту гадость...
Сказали "бе", а добавить "а." - пример лучшей альтернативы?
А что взамен предложить можете?
> Как этот CUPS задолбал, в каждый дистриб суют эту гадость…не ставь. у меня вот не принтера — я и не ставлю.
gentoo, minimal, правильные USE.
Там еще MIPS есть, Qualcomm процессоры, и много чего другого
Он и ARM выпускает. MIPS и DSP как-бы слишком специфичны.
Debian - я не ошибаюсь - что это первый дистрибутив, который неровно задышал к Clang/LLVM ? А совсем недавно _русские студенты_ говорили, что Clang не нужно
> Debian - я не ошибаюсь - что это первый дистрибутив, который неровно
> задышал к Clang/LLVM ? А совсем недавно _русские студенты_ говорили, что
> Clang не нужноузер294 сейчас прийдет и в место того, что бы утереться, опять будет кричать, что все туфта, подумаешь х86, да он же еще фиговый код для арм генерит и нет многих поддерживаемых платформ... некоторым нужно все и сразу... так бы про свою бтр, любимую, распространялся...
А в gnu собираются, интересно, какое-нибудь подобие clang вводить?
> А в gnu собираются, интересно, какое-нибудь подобие clang вводить?gcc. пока что шланг его упорно догоняет.
Да уже какбэ наоборот. gcc умер. И я об этом говорил чуть ли не год назад.
Ну! Живее всех живых. Clang у него очень активно прёт "фишки". Именно в этом-то и причина такой "неожиданной" совместимости. В minix3 gcc поставляется только как дополнительный компилятор, и не просто так. Мне, лично, трудно расценивать clang, как полноценный компилятор из-за малого количества поддерживаемых архитектур. Новость больше похожа на вброс от яблока или гугла, не встречал подробного сравнения от независимых экспертов... Надо будет заняться.
почему «вброс»? люди работают. хороший, годный компилятор. вполне себе «полноценный». ты с таким рвением и icc «неполноценным» объявишь же.
Было уточнение, что мой скептицизм связан со спецификой моей работы.
> Было уточнение, что мой скептицизм связан со спецификой моей работы.пардон, тут не сразу поймёшь, у кого «неполноценный» означает «никому ненужная фиготень», а у кого «для меня малополезно». приношу извинения, что принял за первого.
> Debian - я не ошибаюсь - что это первый дистрибутив, который неровно задышал к Clang/LLVM ?А при чем здесь дебиан? Разве тот факт, что какой-то дядя решил поэкспериментировать, характеризует общую политику проекта?
Пока без патчей, ядро не будет компилить, в продакшон не пустят.
за что минусуют? человек истину изрёк.или это минусуют клоны айзенов и прочих бсданутых товарищей, слюной брызжащие на всё ГНУтое?
> за что минусуют? человек истину изрёк.
> или это минусуют клоны айзенов и прочих бсданутых товарищей, слюной брызжащие на
> всё ГНУтое?не на все. А на то как gcc ложит болт на стандарт языка C и навязывает кучу линуксизмов.
На то что куча майданутых "чукче писателей" не знают что есть стандарты - и впиливают linux зависимый код - вместо написания переносимых вещей.
Хотя приспешникам Столмана это не понять - у них есть религия - им больше не надо.
Пример болта вы конечно привести не в состоянии?
http://clang.debian.net/Ссылка из топика, листать до конца таблицы, смотреть третий пункт:
> g++ accepts codes which should be rejected by the compiler. See ...с примерчиками.
Этого хватит?
вау! целых три примера! действительно, gcc глобально забил на стандарт. причём один пример — таки баг, о котором в gcc сообщили и починят, а два других по-сути одно и то же, и багом/забитием это назвать достаточно сложно.epic win, без сомнения! ты просто уничтожил всех оппонентов столь мощными пруфами!
а где пруфы про «gcc навязывает линуксизмы»? будут? или всё-таки ты признаешь, что в обоих случаях написал не более, чем обычную ерунду?
Я другой Анон.Ты хотел увидеть пример накладывания gcc болта на стандарт, я тебе его привел. Что не так?
Про «gcc глобально забил на стандарт» — это ты сам придумал.Пруфов про «gcc навязывает линуксизмы» от меня не жди, в этой теме я «плаваю».
Заканчивай ерунду писать. Да, clang пока не может _полностью_ заменить gcc, но во многих реальных задачах он уже сопоставим с gcc. И он уже имеет реальное применение — приложения под iOS в Xcode-е собирают как раз им.
Тут кто-то писал, что недостаток clang-а в малом числе поддерживаемых архитектур. Ну так это проблема не clang, а реализации llvm под конкретную архитектуру. Будет llvm4{mips,alpha,...} — clang его подхватит.
Другие говорят, что проблема clang-а в слабой лицензии. Товарищи, никто у вас clang не заберет, максимум, что могут сделать проприетарщики, это форкнуть его и переманить разработчиков. Ну так это нормально. Я считаю, что если жизнь проекта поддерживает только его строгая лицензия, то у этого проекта явно есть проблемы, и надо что-то с этим делать.Я лично, как разработчик, десятки раз посылал лучи «счастья» авторам GPL-библиотек: вместо того, чтобы использовать готовый продукт по своему усмотрению, что сулит выгоды как мне, так и этому продукту, я был вынужден писать свой велосипед.
> Я другой Анон.это было ни разу не очевидно.
> Ты хотел увидеть пример накладывания gcc болта на стандарт, я тебе его
> привел. Что не так?(печально) а уж как шланг кладёт болты на стандарты… ты вообще разницу между «баг» и «нам пофигу на стандарт» видишь, нет?
> Заканчивай ерунду писать.
вот именно.
> Да, clang пока не может _полностью_ заменить gcc, но
> во многих реальных задачах он уже сопоставим с gcc.этот пассаж к чему вообще?
> И он
> уже имеет реальное применение — приложения под iOS в Xcode-е собирают
> как раз им.раз за него.
> так это проблема не clang, а реализации llvm под конкретную архитектуру.
ты знаешь, если мне надо собрать нечто под архитектуру, с которой шланг не дружит, мне сугубо фиолетово, чья там проблема. результат в итоге простой: «нишмагла».
потому что если использовать твою логику, то можно сказать, что gcc на самом деле быстрый как молния, просто его ещё не ускорили. смешно, правда? а это не более, чем перефразирование твоего утверждения.
> Будет llvm4{mips,alpha,…} — clang его подхватит.
будет более быстрый оптимизатор — все компиляторы из набора gcc его подхватят. сюрпрайз? это *вообще никакой не аргумент*. утверждения, где фигурирует нечто вроде «когда будет, так сразу…» рассматривать даже не смешно.
> Другие говорят, что проблема clang-а в слабой лицензии.
это не ко мне, мне вообще пофигу, какая там лицензия: я в разработке участия не принимаю.
> Я лично, как разработчик, десятки раз посылал лучи «счастья» авторам GPL-библиотек:
> вместо того, чтобы использовать готовый продукт по своему усмотрению, что сулит
> выгоды как мне, так и этому продукту, я был вынужден писать
> свой велосипед.(задумчиво) первым делом если подхватываю какую-то полезную библиотеку, меняю лицензию на GPLv3+. «господь велел делиться — стало быть, делись!» (ц)
>http://clang.debian.net/
>Ссылка из топика, листать до конца таблицы, смотреть третий пункт:
>> g++ accepts codes which should be rejected by the compiler. See ...
>с примерчиками.
>Этого хватит?Уже пофиксили в 4.7.0: http://gcc.gnu.org/gcc-4.7/changes.html
См. раздел "New Languages and Language specific improvements" -> "C++".
> Уже пофиксили в 4.7.0фанбоям пофигу. у них ошибка в gcc называется «забивает на стандарты». а ошибка в шланге — «динамично развивается».
пока Clang не пытается изобрести собственный стандарт C.
что делает GNU (hint GNU89).
Да да у GNU паралельная вселенная где с стандартами не считаются.
Стойте .. где-то я уже такую видел - у Майкрософта :)
Точно. 2 сапога пара..
> пока Clang не пытается изобрести собственный стандарт C.
> что делает GNU (hint GNU89).Зачем же они такие стандартные на белом лошаке поддерживают "собственные" =нестандартные расширения им. GCC? Разве не дОлжно таким белым и пушистым костьми лечь за Стандарт? Поясните этот затруднительный момент, будьте любезны.
> не на все. А на то как gcc ложит болт на стандарт
> языка C и навязывает кучу линуксизмов.а теперь давай пруфы. и на «ложит болт на стандарт» и на «навязывает линуксизмы».
оно понятно, что ты сейчас поджав хвост убежишь, но а вдруг, вдруг у тебя действительно есть Секретные Пруфы?
> навязывает кучу линуксизмовГотов поспорить, что если эти "линуксизмы" были впервые реализованы в bsd-компиляторе, некоторые вроде вас стояли бы горой за них. Потому что расширения gcc действительно УДОБНЫ, и я не понимаю, почему бы их не реализовать в других компиляторах. Никаких коммерческих тайн и патентов над ними не висит, документация открыта - реализовывай наздоровье. Их в стандарте нет? Ну и сколько нам ждать, пока сферические писатели стандартов снизойдут до нового релиза?
clang умеет большинство gccзмов хоть и ругается на них. А ядро он не собирает по причине некоторых косяков со встроенным ассемблером.
если в кране нет воды, виновата BSD. если в кране есть вода, BSDшник сс*л туда.сначала неистовые визги LLVM/CLang страшно нужно BSDшникам и только, теперь "BSDшники минусуют".
О, кайф. А у Clang тоже скомпилированный в версии 3.0 бинарник не работает в системе с 2.9?
> О, кайф. А у Clang тоже скомпилированный в версии 3.0 бинарник не
> работает в системе с 2.9?Он юзает gccшные stdlibc++ и glibc. Ну а своя libcxx пока ни разу еще не релизилась.
Если можно легко заменить программы gnu ,другими -на bsd лиценз . Так и Столлмана скоро на пенсию отправят .
Не отправят. К счастью, в мире не все такие беспечные как вы.
Да clang здорово ловит ошибки в C проектах, если бы еще в C++...
Но пока gcc делает его по скорости.
> Но пока gcc делает его по скорости.у меня clang++ быстрее раза в 1,5-2.
Я так думаю имеется в виду вовсе не скорость сборки.
http://www.opennet.me/opennews/art.shtml?num=32245
> Да clang здорово ловит ошибки в C проектах, если бы еще в C++...
> Но пока gcc делает его по скорости.Скорость сборки - параметр конечно важный, но до разумных пределов далеко не самый критичный. Опять же, g++ сегодня так же ооочень далек от ракеты на более-менее тяжелых C++ проектах.
> Скорость сборки - параметр конечно важный, но до разумных пределов далеко не
> самый критичный. Опять же, g++ сегодня так же ооочень далек от
> ракеты на более-менее тяжелых C++ проектах.PS: И да, такое ощущение, что чем дальше и старше версия gcc тем тормознее он собирает C++ код :-/
PPS: Это я ещё про потребление памяти при этом не говорю - кушает как свинья апельсины. С тем же тенденциями.
> PS: И да, такое ощущение, что чем дальше и старше версия gcc
> тем тормознее он собирает C++ код :-/
> PPS: Это я ещё про потребление памяти при этом не говорю —
> кушает как свинья апельсины. С тем же тенденциями.за это можно смело благодарить тех товарищей, которые нам вовсе не товарищи, и тащуть в c++ всё, до чего дотянуться могут. а бедному компилятору за них отдуваться приходится.
ничего, будет ещё медленней — по мере реализации новых и новых фич из нового стандарта.
> за это можно смело благодарить тех товарищей, которые нам вовсе не товарищи, и тащуть в c++ всё, до чего дотянуться могут. а бедному компилятору за них отдуваться приходится.Причем тут стандарт то и новые фичи? boost/asio иди boost/intrusive уже сто лет в обед и весь ченжлог за последние несколько лет - это багфиксинг. А вот собирается оно все медленнее и медленнее.
> Причем тут стандарт то и новые фичи?да нет, что ты, совсем не при чём.
> boost/asio иди boost/intrusive уже сто лет в обед
и что?
> и весь ченжлог за последние несколько лет
чей?
впрочем, дальнейший разговор бессмысленен, коль скоро ты не разделяешь фичи языка и стандартных библиотек.
ccache дает куда более суровый прирост при разработке чем замена gcc на clang
> Да clang здорово ловит ошибки в C проектах, если бы еще в
> C++...
> Но пока gcc делает его по скорости.Недавно тестировал скорость сборки Firefox 10.0.2 системным GCC 4.2.1 и системным LLVM/Clang 3.0:
% cc --version
cc (GCC) 4.2.1 20070831 patched [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.% time portmaster -gD --delete-build-only firefox-10.0.2,1
=========================================================================>>> Done displaying pkg-message files
===>>> Re-installation of firefox-10.0.2,1 complete
2745.130u 325.617s 20:09.36 253.9% 7289+4392k 11796+584172io 8308pf+0w
% ls /store/pckgs64/All/firefox-10.0.2,1.tbz
-rw-r--r-- 1 root wheel 30M Feb 27 20:31 /store/pckgs64/All/firefox-10.0.2,1.tbz% /usr/bin/clang --version
FreeBSD clang version 3.0 (tags/RELEASE_30/final 145349) 20111210
Target: x86_64-unknown-freebsd9.0
Thread model: posix% time portmaster -gD --delete-build-only firefox-10.0.2,1
=========================================================================>>> Done displaying pkg-message files
===>>> Re-installation of firefox-10.0.2,1 complete
1810.805u 208.605s 13:16.48 253.5% 26336+1608k 12245+408227io 33809pf+0w
% ls /store/pckgs64/All/firefox-10.0.2,1.tbz
-rw-r--r-- 1 root wheel 27M Feb 27 20:51 /store/pckgs64/All/firefox-10.0.2,1.tbzПеред каждым тестом правился /etc/make.conf на предмет использования необходимого типа компилятора, а машина перезагружалась, чтобы не "греть" ARC кэш ZFS. В обоих случаях помимо сборки был запущен Xorg с менеджером входа в систему Slim без логина пользователя в графическую оболочку. Компиляция выполнялась в текстовой консоли.
изя, лапочка, ты бы ещё потестировал скорость сборки си-проектов при помощи gcc и tcc, тоже было бы архиполезно.хинт для изи: собирают обычно один раз. используют — много. тормоза на стадии сборки окупаются более шустрым исполняемым кодом. такие дела.
> тормоза на стадии сборки окупаются более шустрым исполняемым кодом. такие дела.Нет. (С)
Эти вещи никак не связаны. Более того, тот факт, что C-Lang делает исполняемый код меньшего размера, _может_ позитивно отразиться на производительности.
А может и не отразиться, но это надо Изю попросить попрофайлить.
>> тормоза на стадии сборки окупаются более шустрым исполняемым кодом. такие дела.
> Нет. ©как это? O_O
> Эти вещи никак не связаны.
*где* не связаны?
я разве где-то утверждал, что код gcc в итоге быстрее? я, вообще-то, специально написал в общем виде, куда уж ясней? намекнул изе, что его «тесты» — бессмысленный мусор, и что надо проверять выхлоп, а не скорость сборки. если у clang и выхлоп шустрее — ок. если нет — нет.
Изену просто нужно было за что-то уцепиться, и это оказалась скорость сборки. Если бы Clang собирал медленнее gcc, но при этом писал бы в консоль анекдоты, Изен бы, поди, и это привел в качестве разгромного превосходства над gcc
> Изену просто нужно было за что-то уцепиться, и это оказалась скорость сборки.
> Если бы Clang собирал медленнее gcc, но при этом писал бы
> в консоль анекдоты, Изен бы, поди, и это привел в качестве
> разгромного превосходства над gccСам посуди: ждать сборки и установки всех нужных портов 12 часов или уйти куда-то на 5 часов, а потом прийти, а всё уже собрано, что приятно, первое или второе? Мне приятнее второй случай.
На десктопе, запуская ИНТЕРАКТИВНЫЕ десктопные приложения не так важно, что код, созданный Clang, выполняется на 15 миллисекунд дольше, чем супероптимизирвоанный код, созданный GCC 4.2. :))
Обновления выходят регулярно: http://www.freshports.org/
Система и приложения обновляются часто == нет авралов при переходе с версии на версию. Вот где скоростной компилятор имеет приоритет перед низкоскоростным и задумчивым.
давай продолжим твои рассуждения дальше: вот я, например, пнул апгрейд, и он за час всё из репозиториев достал да поставил. и «На десктопе, запуская ИНТЕРАКТИВНЫЕ десктопные приложения не так важно, что код», не собраный под конкретную архитектуру, «выполняется на 15 миллисекунд дольше, чем супероптимизирвоанный код, созданный» неважно-каким-компилятором.откуда вывод: бинарные пакеты рулят, clang не нужен. опаньки, изя?
> давай продолжим твои рассуждения дальше: вот я, например, пнул апгрейд, и он
> за час всё из репозиториев достал да поставил.Представь себе, у меня нет каких-то там левых и непроверенных репозиториев. Я предпочитаю собирать программное обеспечение из исходных тектов, полученных из авторизованных источников или прямо с сайта автора кода. Целостность исходников подтверждена хэшем SHA1, который хранится в каталоге порта коллекции портов, а не где-то там в интернетах. Также я предпочитаю контролировать зависимости библиотек и других программ и их необходимость для конкретной программы. Собираемые бинарные пакеты доступны всем клиентам в локальной домашней сети.
> и «На десктопе,
> запуская ИНТЕРАКТИВНЫЕ десктопные приложения не так важно, что код», не собраный
> под конкретную архитектуру, «выполняется на 15 миллисекунд дольше, чем супероптимизирвоанный
> код, созданный» неважно-каким-компилятором.
> откуда вывод: бинарные пакеты рулят, clang не нужен.Бинарные пакеты рулить могут там, где не важно, какой мусор установлен в системе. Как работают мозги у мантейнеров пакетов, которые считают нужным прицепить к тележке действительно нужного целый ЛОКОМОТИВ ненужного хлама, тянущегося по зависимостям.
> опаньки, изя?
Не называй меня изей. Тех, кто меня называет "изей", я глубоко презираю и считаю ниже своего достоинства общаться с такими отбросами IT-сообщества.
> Бинарные пакеты рулить могут там, где не важно, какой мусор установлен в системе.Обратное утверждение верно.
А Вы наивны, когда думаете, что соберёте что-то лучше стопки понимающих в своих областях майнтейнеров. В лучшем случае воспроизведёте чужой результат (потому, что он был достаточно квалифицированно оформлен, чтобы даже Вы смогли).
В качестве reality check можете поинтересоваться доверием к фре и редхату там, где действительно *важно*, что же работает в системе.
>> Бинарные пакеты рулить могут там, где не важно, какой мусор установлен в системе.
> Обратное утверждение верно.
> А Вы наивны, когда думаете, что соберёте что-то лучше стопки понимающих в
> своих областях майнтейнеров. В лучшем случае воспроизведёте чужой результат (потому,
> что он был достаточно квалифицированно оформлен, чтобы даже Вы смогли).В элитизм мантейнеров не верю. Это сборщики. Авторы продуктов гораздо лучше разбираются в вопросах зависимостей собственных творений от сторонних библиотек, а мантейнеры всего лишь стараются следовать (хорошие мантейнеры) или плюют (плохие мантейнеры) на рекомендации авторов программ.
> В качестве reality check можете поинтересоваться доверием к фре и редхату там,
> где действительно *важно*, что же работает в системе.У меня всё работает с 2006 года, постоянно обновляясь методом пересборки из исходников по тем правилам, что записаны в дереве портов. На косячки мантейнеров и исправления правил сборки, удаления ненужных зависимостей я уже насмотрелся.
> В элитизм мантейнеров не верю. Это сборщики. Авторы продуктов гораздо лучше разбираютсяМентейнеры, с которыми приходится сталкиваться мне, зачастую производят
впечатление гораздо больших профессионалов, чем авторы софта, который
они пакетят. Плохой программист или непрограммист вообще не может
стать (хорошим) ментейнером. Про админов и "пользователей" я вообще молчу.
>> В элитизм мантейнеров не верю. Это сборщики. Авторы продуктов гораздо лучше разбираютсяДа при чём тут элитизм... я вот не верю (основываясь на вещаемом Вами тут), что *Вы* разбираетесь хотя бы в чём-то не гораздо, а просто лучше майнтейнера соответствующей подсистемы в любом приличном линуксовом дистрибутиве. Не говоря уже обо всём множестве используемых программных пакетов.
По поводу своей компетенции в вопросах сборки, скажем, libc или компиляторов у меня иллюзий точно нет. :)
> Ментейнеры, с которыми приходится сталкиваться мне, зачастую производят
> впечатление гораздо больших профессионалов, чем авторы софта, который
> они пакетят. Плохой программист или непрограммист вообще не может
> стать (хорошим) ментейнером. Про админов и "пользователей" я вообще молчу.Ну майнтейнеры экстра-класса -- это вообще отдельное явление: что ни потрогают, то позолотят :) Но как показывает практика, вдумчивый админ может быть неплохим майнтейнером софта с хорошим апстримом. Да, в код он может и не заглядывать, но README с INSTALL прочтёт и опыт развёртывания/эксплуатации учтёт -- меньше типовой мороки пользователю.
Дело немного в другом: жёлуди-то (хоть пакеты, хоть порты) не в вакууме растут.
> бинарные пакеты рулят, clang не нуженУ меня софты собраны с моими либами, с моими опциями компиляции, с моими твиками под архитектуру и - главное! - без кучи мусора для совместимости с абстрактной среднестатистической системой. Один тот факт, что эквивалентная по функционалу система содержит не 600+ пакетов, а всего полторы сотни софтов из сырцов, сокращает эксплуатационные издержки вдвое.
Пакеты - отличный способ собрать новую систему из незнакомых софтов. Но после некоторого знакомства и анализа пересборка с оптимизацией неизбежна.
я рад за тебя. но мы тут обсуждали принципы оценки нашего изи, а не «надо или нет собирать пакеты руками».p.s. не надо, если ты не админ локалхоста.
> я рад за тебя. но мы тут обсуждали принципы оценки нашего изи,Ну не хуже фороникса какого :)
> а не «надо или нет собирать пакеты руками».
> p.s. не надо, если ты не админ локалхоста.Ути пуси - у нас дэйтацентр 20 рядов по 25 47U шкафов, в каждом от 1 до 5 chassis, в каждом от 5 до 14 IBM HS22 ... и таки _собираем_, ибо иначе - сильно дороже :(
Ессно собираем единожды а потом puppet и кой какая самодельшина разносят.
PS: А ты таки оиделосЪ как тебя приложили :) Ну может и сам поакуратней станешь с обзывалом :)
> Ути пуси - у нас дэйтацентр 20 рядов по 25 47U шкафов,
> в каждом от 1 до 5 chassis, в каждом от 5
> до 14 IBM HS22 ... и таки _собираем_, ибо иначе -
> сильно дороже :(а у меня свой космодром, чо. ты, кстати, проспал утреннюю сборку пакетов.
> таки _собираем_, ибо иначе - сильно дороже :(Разумеется. Пакет - хорошо, когда он свой. И никто не мешает держать собственную репу.
Кстати, насчет "сильно дороже". По моим прикидкам самосбор снижает ТСО примерно на треть. А у вас?
<trollmode>
Вообще-то, третье. Когда все устанавливается из готовых пакетов. Хотя...ну да, во фре же нет нормальной системы пакетов :)
</trollmode>
> А может и не отразиться, но это надо Изю попросить попрофайлить.Просим, маэстро, просим!! Не, серьёзно. По-взрослому -- с "холодной перезагрузкой", [без X-ов, безголовых : вырезано самоцензурой] тестов броузера кучку... В Фороникс-Тест-Сьюте ФФ часть присутствует?? Во!
Фороникс-Тест-Сьют уже "есть в портах"ТМ? Ась??
А проверять не пробовали то, что собралось? Чтобы не было, как в том анекдоте, "но такая ерунда получается".
До них, наконец, ДОШЛО.P.S.
Использую системный LLVM/Clang 3.0 для сборки системы и портированных программ на FreeBSD. В сравнении с GCC 4.2 скорость компиляции и сборки существенно (до 30%) возросла. Только GCC собираются незначительное количество портированных программ — исключения для них в /etc/make.conf:.if !empty(.CURDIR:M/usr/ports/*)
.if empty(.CURDIR:M/usr/ports/www/libxul*) \
&& empty(.CURDIR:M/usr/ports/net-p2p/libtorrent-rasterbar*) \
&& empty(.CURDIR:M/usr/ports/audio/wavpack*) \
&& empty(.CURDIR:M/usr/ports/audio/libaacplus*) \
&& empty(.CURDIR:M/usr/ports/x11/menu-cache*) \
&& empty(.CURDIR:M/usr/ports/x11/libfm*)
CC=clang
CXX=clang++
CPP=clang-cpp
# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
#-NO_FSCHG=
.endif
.endif
Пф-ф-ф, во FreeBSD в распоследней идет gcc 4.4.1. Нашел с чем сравнивать. Из портов, конечно, можно поставить, только вот компилиться он из портов будет через 4.4.1 ))) В DragonFly и то 4.4.7
>Пф-ф-ф, во FreeBSD в распоследней идет gcc 4.4.14.2.1
>Из портов, конечно, можно поставить, только вот компилиться он из портов будет через 4.4.1 )))
Ну и что? Собираем 4.6 из портов с помощью 4.2.1, который идет с базовой системой, а дальше пользуемся 4.6 для компиляции всего остального. В чем проблема? Я так еще год назад делал.
> Пф-ф-ф, во FreeBSD в распоследней идет gcc 4.4.1. Нашел с чем сравнивать.
> Из портов, конечно, можно поставить, только вот компилиться он из портов
> будет через 4.4.1 ))) В DragonFly и то 4.4.7а какие проблемы апосля самого себя пересобрать самим собой?
>а какие проблемы апосля самого себя пересобрать самим собой?Вообще-то это обычный способ сборки gcc. Всегда версия собирает сама себя.
>>а какие проблемы апосля самого себя пересобрать самим собой?
> Вообще-то это обычный способ сборки gcc. Всегда версия собирает сама себя.Кстати, а почему шланг так не делает? Он же на такое способен!
>>>а какие проблемы апосля самого себя пересобрать самим собой?
>> Вообще-то это обычный способ сборки gcc. Всегда версия собирает сама себя.
> Кстати, а почему шланг так не делает? Он же на такое способен!почему не делает? вполне себе делает.
>>а какие проблемы апосля самого себя пересобрать самим собой?
> Вообще-то это обычный способ сборки gcc. Всегда версия собирает сама себя.ну так и шланг так же, что тут удивительного?
> Пф-ф-ф, во FreeBSD в распоследней идет gcc 4.4.1.% /usr/bin/cc --version
cc (GCC) 4.2.1 20070831 patched [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% uname -rsm
FreeBSD 9.0-STABLE amd64> Нашел с чем сравнивать.
> Из портов, конечно, можно поставить, только вот компилиться он из портов
> будет через 4.4.1 ))) В DragonFly и то 4.4.7Из портов можно поставить:
gcc42 4.2.5.20090325_5
gcc44 4.4.7.20120117
gcc46 4.6.4.20120302
gcc47 4.7.0.20120225Перевод системы компиляции и сборки FreeBSD на другую версию GCC описан здесь:
http://www.freebsd.org/doc/ru/articles/custom-gcc/article.html
Debian переходит на Clang? это было бы клева :)
то что RedHat не перейдет - факт, ибо gcc - это его корова - а вот Debian вполне может.
> Debian переходит на Clang? это было бы клева :)
> то что RedHat не перейдет - факт, ибо gcc - это его
> корова - а вот Debian вполне может."Debian переходит на mips/mipsel/armel/powerpc/sparc ? это было бы клева :)"
Никуда Debian не переходит. Он раскидывает щупальца.
>> Debian переходит на Clang?
> "Debian переходит на mips/mipsel/armel/powerpc/sparc ?Да чё там, Дебиан прешёлд же на FreeBSD уже. И на Hurd. </великие анинимные открытия>
А в прошлом, говорят, Debian перешел на win32. Но с тем проектом не срослось из-за блокировок исполняемых файлов.
> А в прошлом, говорят, Debian перешел на win32.Если имеется ввиду Debian/Interix, то не win32, а winnt.
Interix работает поверх winnt, а не win32, в отличие от, скажем, cygwin-а.
Вы новость прочитайте, хотя бы осильте последний абзац :)
С кем бы поспорить на миллион, что первым кто на него перейдёт будет Fedora?...
> С кем бы поспорить на миллион, что первым кто на него перейдёт будет Fedora?...Во-первых, миллиона у тебя нет и на слово тебе никто не поверит.
Во-вторых, РэдХэту оно ни во что не впёрлось.
В-третьих, первым [и последним перешедшим "linux"-ом] будет fbsd 10. Любой _перешедший **полностью** захлебнётся и не выживет.
Для тех, кто невнимательно прочел новость: никто никуда не переходит. Взята пакетная база Дебиана и на ней проведен некий эксперимент. С тем же успехом это можно было на гентовском портаже провести, к примеру.
>Интерес также представляли расширенные возможности Clang по выводу информации о возможных ошибках и недоработках, учёт которых позволил бы повысить общее качество кодовой базы.Так что даже если в репах и на болванках выкладывать пакеты собранные GCC, то параллельная сборка с помощью clang была бы полезна всем. Если сообщество Debian отважится перейти от экспериментов к поддержанию постоянной инфраструктуры для сборки clang'ом будет замечательно.
Это дело разработчиков, вообще-то. И анализ варнингов должны делать именно они, а не дебиановские маинтайнеры. Обратную ситуацию могу напомнить - Debian, ssh.
> Это дело разработчиков, вообще-то. И анализ варнингов должны делать именно они, а
> не дебиановские маинтайнеры. Обратную ситуацию могу напомнить - Debian, ssh.Лучше напомнить OpenSSL в котором сломали безопастность :)
Я-то по заголовку подумал что тут про скорость бинарников речь. А тут о том, что собирается далеко не всё.
Ну прогресс, очевидно, есть. Раньше он у меня падал, а теперь просто выдает ошибки компиляции.
Конкуренция в GNU и альтернатива ключевым продуктам, таких как GCC x.org никогда не помешает и всегда идёт на пользу обоим, включая конечных пользователей :))
Посмотрим что из этого выйдет...
поддерживаю, пример firefox и chrome тому подтверждение
> поддерживаю, пример firefox и chrome тому подтверждениеэто в пример ставится накрутка версий в лисе что-ли? расскажите, что в этом полезного?
новые фичи и поддержку новых стандартов HTML5 из nightly пользователи получают не через год-два, а через 3-4 месяца
тут было что и MINIX собирают Clang'ом. Тенденция?
Интересно что получилось с качеством собраных бинариков. Не улучшилась ли производительность или потребление памяти?
интересно вообще работают ли они?
Потребление памяти уменьшается на 1-2%. Скорость падает на 5-10%. Стабильность работы, как ни странно, растет, хотя точно измерить затруднительно. Это у меня на рабочих проектах, но не думаю что у дебиана сильно иначе.
>Не улучшилась ли производительность или потребление памяти?Не поверишь, он их не то что не _запускал(*), но даже тупо размеры бинарников обещает посчитать как-нибудь в следующий раз.
(*)И кстати, как вы [все!!, задающие _этот _тупой вопрос,] представляете себе проверку запускабельности, _изменения производительности и _изменения потреблибельности для 28000+ пакетов -- желательно ***скриптом***????
> В то время как Clang в полной мере пока поддерживает только архитектуры X86-32, X86-64 и ARM.А разве поддержка арма доступна в открытой версии clang? Вроде ж оно было только в проприетарной версии от яблока.