Вышел LLVM/Clang 3.9

Сборку с multilib в gentoo исправили? Или оно так же ругается, что выбранный процессор не умеет 64 бита?

RMS о Clang: https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html

Только вчера 3.8.1 собрал. :/

RMS о Clang: https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html

И я его полностью поддерживаю!

RMS о Clang: https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html

Наша свобода свободистей чем ваша, потому-что мы больше запрещаем в нашей лицензии.

Вышел, да не весь. Пакаджей еще нет. Как грицца, «ждем ебилдов» ...

Кстати, посмотрел я тут недавние тесты gcc vs clang на форониксе: http://www.phoronix.com/scan.php?page=article&item=freebsd11-clang-gcc&am...

Одной из киллер-фич clang была быстрая компиляция, а теперь, когда clang начал парировать gcc по производительности генерируемого кода, скорость компиляции сравнялась с gcc))

Так никто не мешает что clang, что gcc на этапе разработки запускать с -O0. А для быстрой сборки релизов можно и distcc использовать.

Так никто не мешает что clang, что gcc на этапе разработки запускать с -O0. А для быстрой сборки релизов можно и distcc использовать.

Именно, более того - с включенной оптимизацией clang и раньше не особо быстрее gcc был.

начато внедрение возможностей стандарта C++1z, которые активируются ключом -std=c++1z;

std::string_view.

Nested namespace definition

Folding expressions

A file system library based on boost::filesystem

Я знал что дождусь.

Просто это был их selling point, которым всех задалбывали длительное время этими же сравнениями, а теперь вот умолкли. Это то и забавно.

Не скажите. На gentoo с -O2 у меня Firefox компилировался цлангом в 2 раза быстрее, чем гэцацой.

начато внедрение возможностей стандарта C++1z, которые активируются ключом -std=c++1z

Спасибо, я кончил.

Скажите кстате что там с Apple? В Xcode когда появится?

PS: а то всё gcc использую...

Даже не знаю, от чего блевать хочется больше — от автолулзов или от СMake.

Больной человек. Мне его жаль.

От последнего. Хотя бы потому, что его авторы видели autotools и могли сделать лучше, а сделали CMake. У первого в качестве оправдания то, что он переиспользует код m4, у второго адекватных оправданий нет (я знаю, что они хотели сделать нечто близкое к autotools, но могли бы и не брать адский синтаксис).

Это не нужно, есть 8cc, на крайний случай tcc.

Казалось бы, причём тут система сборки?

Казалось бы, причём тут система сборки?

Она фигурирует в новости. Прочитай ещё раз.

в качестве оправдания то, что он переиспользует код m4

А что в этом плохого?
Я не девелопер, когда-то autotools постоянно бесил тем, что каждая свежая софтина требовала более свежего autotools. Который требовал более свежего... и т.д.

Больной человек. Мне его жаль.

Когда на тебя электронный ошейник с намордником накинут, вспомни эти слова, дебил.

в качестве оправдания то, что он переиспользует код m4

А что в этом плохого?

В переиспользовании? Ничего. Я к тому, что там правила экранирования и разделения аргументов сложные, но тому есть вполне понятные причины, а подражателям не следовало копировать эти элементы, которые в autotools вынужденные.

Я не девелопер, когда-то autotools постоянно бесил тем, что каждая свежая софтина требовала более свежего autotools. Который требовал более свежего... и т.д.

Сборка проекта на autotools не должна ничего требовать, в этом его прелесть. Если оно требовало для пересоздания каких-то файлов, то значит софт паковали неправильно (правильно это `make dist` или `make distcheck`). В таких случаях достаточно сделать несколько вызовов touch и всё соберётся без проблем.

разработчики отказались от поддержки autoconf в пользу CMake

Везде бы так. CMake божественен!

Сколько ошибок в слове qbs.

Даже не знаю, от чего блевать хочется больше — от автолулзов или от СMake.

От CMake, естественно. Автотулзы хотя бы делали грамотные люди.

Это что, можно наконец скомпилировать жыэс в жыэс чтобы быдло- и интересный код скрыть?

CMake

Годно, нужно, прекрасно.

ThinLTO

same

гцц, RMS, швабодка

*пожимаю плечами*

Да ну их в задницу. Писал бэкенд, все собиралось. Последний коммит в мае. Вчера попробовал пересобрать. Они поменяли половину api, ошибки в каждом файле. Юмористы блин.

разработчики отказались от поддержки autoconf в пользу CMake;

фу, закопайте, больше не нужно

разработчики отказались от поддержки autoconf в пользу CMake;

фу, закопайте, больше не нужно

Тебе то какая разница?

autoconf-ом собирать софт приятнее

Грамотные люди столько костылей не нагородят :)

Мне кажется, ты не понимаешь, в каких условиях они работали и какие цели перед собой ставили.

Наша свобода свободистей чем ваша, потому-что мы больше запрещаем в нашей лицензии.

Главное то кому запрещают. Уверен что ты никогда не станешь тем кому эта лицензия что-то запрещает, в крайнем случае ты на них будешь работать, какое-то время, потом заменят.

Да ну их в задницу. Писал бэкенд, все собиралось. Последний коммит в мае. Вчера попробовал пересобрать.

Писал на unreleased версии? Или попробовал перейти со старого релиза на новый?

Сейчас C++ и Pascal как бы поменялись местами, по сравнению с ситуацией 80-х и начала 90-х.

Free Pascal проигрывает C++ только отсутствием специфических оптимизированных либ которые используют в бенчмарках производительности.

Для современной ОС нужен простой системный язык с модульностью, ООП и быстрой компиляцией. Язык для которого можно создавать хорошие IDE просто на основе парсера(в C typedef не позволяет), которые были бы на уровне Java IDE. Язык не требующий больших изменений из-за недостатков обратной совместимости, который был во многом продуман изначально. Это только Free Pascal.

Годно, нужно, прекрасно.

А чем лучше автолулзов? :)

Больной человек. Мне его жаль.

Если бы вопрос библиотек книг был на повестке в наше время, то типографии лоббировали бы их закрытие, любыми способами, вплоть до их скупки и превращения в магазины. Хотя... это во многом так и происходит. Связи с политиками у них есть так как печатают предвыборные буклеты.

А зачем эти книги? Есть же wikipedia и stackoverflow с githu... aaaa, вот оно что...

И тебя тоже уже не вылечат. Как жаль.

это карма)

clang в отличие от gcc можно из trunk собирать и пользовать, там все так густо тестами и билд фермами покрыто что сырые патчи не проходят.

Как минимум тем, что может в кросс-платформу без UNIX-овых костылей.

Хотя CMake та ещё неочевидная параша. А регистронезависимость ихнего DSL это вообще из винды что ли пришло?

попытался переползти с 3.8.1 (вроде, или 3.8.0) на нынешний 3.9. И сразу половина кода поплыла. Где-то теперь void вместо boolean, где-то нужно передавать указатель вместо объекта и наоборот, где-то инклюд перевесили в другую директорию и класс переименовали...

не, все фигня конечно, но это хрен в каждом чертовом файле по 20 раз.

У условиях военного времени под пулями?...

Вот и я о том же. Хотели как лучше, а получилось как всегда.

Когда-нибудь пробовал компилять автотулзный проект под вендой? :)

И вообще cmake - ынтырпрайзненько :)

сырые патчи не проходят

Сижу и ржу, вспоминая как я им прислал патч, исправляющий программную реализацию работы с плавающей точкой, а они его ещё и принимать не хотели. Тот код, что у них был, был «заверен» несколькими людьми и «протестирован», и при этом на половине входных данных выдавал мусор. Автор того участка даже не понимал, как работает двоично-дополнительный код, и делал отрицательное число положительным сбросом старшего бита. И такого там хватает, так что не надо покупаться на рекламный бред, который они несут.

ынтырпрайзненько

Ага. Как Java-программы на десктопе.

В условиях зоопарка из полдюжины разных юниксов и с целью сделать сборку из исходников на всех них переносимой и легкой для конечного пользователя.

А он умеет Ninja?