LINUX.ORG.RU

Широкая дискуссия о будущем GCC

 ,


3

5

В прошедший вторник в список рассылки GCC попало одно письмо, вызвавшее множество ответов и даже интересное обсуждение о будущем GNU Compiler Collection, о его конечных целях и об их достижимости. В первом письме просто был задан вопрос о примерных сроках полной реализации стандарта ISO C++11. Но по мере разрастания нити Diego Novillo из Google, хорошо зарекомендовавший себя в роли разработчика GCC, даже высказал опасения, что GCC уже прошёл точку невозврата и ему грозит естественная смерть.

Нить появилась в списках рассылки во вторник и обновляется по сей день. Также промелькнула ссылка на страницу с отчётом о поддержке C++11 в GCC, но обсуждение ушло в другие области, как то: разработка GCC, привлечение новых разработчиков, выживание ведущего свободного компилятора. А теперь проведём обзор самых интересных комментариев нити.

Дискуссия разгорелась после того, как на резонный вопрос «Когда спецификация C++11 будет полностью воплощена в код?» был получен ответ «Как всегда, не раньше чем добровольцы-ментейнеры воплотят её в код».

Фраза «добровольцы-ментейнеры» в ответе и стала поводом широкого обсуждения о нехватке добровольцев, которые желают (это-то легко) и при этом могут работать над GCC (что намного труднее и удаётся меньшинству). Множество людей, занятых в GCC, участвуют в проекте с незапамятных времён. А сколько кода было написано людьми, пришедшими в 2012 и никогда не работавшими прежде? Стоит рассмотреть такую меру, как улучшение понятности компилятора, посредством, например, больших вложений в проектную документацию. Многие знания о структуре GCC до сих пор остаются лишь в памяти людей, которых в любой день может задавить автобус, перевозящий сотрудников Microsoft.

Затем новым разработчикам, мечтающим о том, чтобы им выпала честь работать над GCC, рекомендовали посетить страницу.

В ответ на предложения по уменьшению входного порога для интересующихся GCC также поступали классические отговорки «Компиляторы — это очень сложные программы» и «едва ли несколько человек хотят и при этом способны написать такую документацию».

Разумеется, были и споры на тему LLVM/Clang. Одним из ответов было «Как вам идея, что Clang влияет на эти сроки, потому что GCC теперь вынужден конкурировать с ним? Clang сейчас немного впереди и GCC должен измениться, если он хочет по-прежнему быть ведущим».

В ответ на это, Diego Novillo, всё ещё работающий в Google, поделился своим мнением:

Я вижу несколько прикладных областей, с которыми Clang/LLVM успешно справляется и в которых GCC, на мой взгляд, пока не стремится участвовать: в частности, «инструментабельность» (toolability), за неимением лучшего слова. Архитектурный дизайн clang следует пути, отличному от g++. Это не просто кодогенерирующий парсер, это прежде всего парсер, который помимо прочего генерирует код (прим. переводчика - см. SemaCodeComplete.cpp в исходниках clang, в т.ч. где вызываются эти функции). Это различие позволяет использовать компилятор в инструментах любого рода, которым нужно знать о семантике C++: в статических анализаторах, при форматировании кода, подсветке синтаксиса и т.д. Вдобавок он реализован как библиотека и может встраиваться в приложения.

Это задачи, которые g++ сейчас не может выполнить. С помощью плагинов он, конечно, может выполнить кое-что из перечисленного, но эти плагины куда сложнее и вынуждены влезать в недра компилятора.

Не факт, что всё это является недостатком g++. Но для эффективной конкуренции в этих областях необходима существенная реорганизация.

LLVM имеет схожие с clang свойства. GCC всё ещё имеет некоторые ограничения в портируемости своих бекендов.

Примечательно и другое письмо про необходимость притока свежих сил из числа молодых студентов и университетских исследователей, которые на данный момент почти повсеместно используют LLVM (прим. переводчика — подтверждаю, и в российских ВУЗах LLVM вытеснил MSIL). В ответ на него уже известный вам Diego Novillo создал в рассылке вторую нить для обсуждения выживания GCC в долгосрочном периоде. Диего думает, что проект уже мог незаметно пройти точку невозврата и компилятор FSF может умереть естественной смертью.

Выживание GCC в будущем является нашей задачей. Порой я думаю, что мы уже пропустили критический момент.

При этом тот ограниченный круг разработчиков, что может выполнить задачу, как полагается, меньше всего желает её выполнять. Конкретно эти разработчики уже на «ты» с кодовой базой, они приучились выполнять задачи, ради которых были наняты и вместе с другими наёмными работниками сформировали некоторый коллектив. К тому же, освоившиеся разработчики чаще всего отвергают изменения, потому что в ближайшей перспективе они дают нестабильность и ошибки (читайте: головную боль ментейнера).

Эволюционное улучшение кода остаётся неблагодарной и трудной работой. Как инженеру, она мне интересна, но я здраво оцениваю свои силы. В рабочее время мы выполняем другие задачи, которые зачастую по природе своей конфликтуют с эволюционированием кода. Некоторые разработчики уже внесли вклад в улучшение кода в плане названной задачи, но суммарный технический долг кода в GCC огромен.

Если этакие тенденции продолжатся, команда опытных разработчиков GCC со временем начнёт вырождаться. Без обновления этой команды GCC ждёт естественная смерть. Этот процесс начался давно и продолжается сейчас. Ну и кроме этого, будет интересно иметь два или более сильных и конкурирующих друг с другом компиляторов. Обмен наработками (прим. переводчика - в оригинале «перекрёстное опыление», намёк на улучшение генов путём спаривания), к которому ведёт любая конкуренция в opensource, в конечном счёте выгодна всем, и пользователям, и разработчикам.

Richard Guenther отвечал на это

«Учтите, что мы не вправе поставить GCC в гараж и рефакторить его два года. Любая починка ведётся прямо на оживлённой трассе! Это существенно ограничивает доступные нам методики рефакторинга, что в итоге может ограничить и выгоду от их применения. Всегда дважды подумайте, прежде чем превращать GCC в ещё большее болото, чем сейчас!

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

От переводчика:

От себя добавлю, что Erik Verbruggen и я продолжаем работу над интеграцией clang в QtCreator, что в конечном счёте будет полезно всем, кто работает с C, C++ и ObjectiveC. Сегодня с утра я добавил ряд исправлений в механизм автодополнения, а в середине февраля либо параллельно с выходом QtCreator 2.7 добавлю сборки последних стабильных версий QtCreator, clang и плагина для нескольких дистрибутивов: скорее всего это будут Ubuntu (ppa), OpenSUSE (buildservice) и ROSA (ABF). Плагин на порядок улучшает диагностику ошибок прямо в ходе редактирования кода и добавляет неплохое автодополнение (в целом лучше, но в кое-чём хуже встроенного).

Для пользователей арча уже есть qtcreator-clang-git в АУРЕ, но я советую не использовать его, а подождать, пока будет принят мой коммит и пока я отпишу ментейнеру пакета с просьбой обновить его, либо собрать плагин с пылу да с жару по этой инструкции, (по желанию) наложить ещё не принятый патч

git fetch https://codereview.qt-project.org/p/qt-creator/qt-creator refs/changes/23/45923/2 && git checkout FETCH_HEAD
после чего (обязательно) открыть файл clang_installation.pri и закомментировать знаком # строку
DEFINES += CLANG_INDEXING
Это отключит временно неиспользуемое, но сильно замедляющее работу индексирование.

>>> Подробности

Чтобы иметь будущее, они должны прикрутить clang к своему отпимизатору

annulen ★★★★★ ()

Я так и не понял, это рассказ о дискуссии в gcc@ или пиар qtcreator-clang %)

tailgunner ★★★★★ ()

Ну... Учитывая, что ничего вечного на этом свете не бывает, всё может быть. Главное, что всё прошло как можно менее болезненно.

drSchur ★★★ ()

не надо забывать, что gcc распространяется под gpl, а clang/llvm — проприетарщина бсдшная, поэтому свёртывание gcc очень больно ударит по спо в целом.

anonymous ()
Ответ на: комментарий от tailgunner

Я так и не понял, это рассказ о дискуссии в gcc@ или пиар qtcreator-clang %)

Это добрейший рассказ плюс продакт-плейсмент.

quiet_readonly ★★★★ ()

Один тролль закинул провокационное письмо в рассылку, другой его покормил. А ITT сейчас начнётся бурление говн по этому поводу.

CYB3R ★★★★★ ()

И почему это в опенсорце так любят всё время что-нибудь закапывать и хоронить? Прямо удивляюсь.

А мне вот думается, что gcc ещё достаточно долго проживёт.

Ну а когда придёт ему конец, то есть же Clang, наверняка ещё что-нибудь появится.

Не запугаете, и не такое видали. :)

DeVliegendeHollander ★★ ()

clang/llvm - это хорошо, но кодогенератор например для х86 сливает начисто gcc.

devl547 ★★★★★ ()
Patch Set 1:
Possible spelling errors in d189bce5b569f5b14a287fa9957d17a4b3177cdb:
  src/plugins/clangcodemodel/completionproposalsbuilder.cpp:
    behaviour -> behavior [*]
    compilant -> compliant (occurs twice)
    throught -> through

Patch Set 2:
Possible spelling errors in ac5b50b59edd1167cfcd6b07ca409c01dcb66b8b:
  src/plugins/clangcodemodel/completionproposalsbuilder.cpp:
    compilant -> compliant

Почему-то позабавило. Spellchecker отвалился?

anonymous ()
Ответ на: комментарий от DeVliegendeHollander

И почему это в опенсорце так любят всё время что-нибудь закапывать и хоронить?

В случае проприетарщины подобные мысли просто не выносятся за пределы компании.

Relan ★★★★★ ()
Ответ на: комментарий от DeVliegendeHollander

И почему это в опенсорце так любят всё время что-нибудь закапывать и хоронить?

Так скучно будет, если никого хоронить/закапывать не будем.

А так — каждый день похороны.

anonymous ()

Прочитал: «Шокирующая правда о gcc!»

fero ★★★★ ()
Ответ на: комментарий от Relan

Мерзософт не так давно гейфон хоронил, кстати %)

anonymous ()

ну... если к Clang/LLVM проектам присоединиться проще и у них есть документация по внутренностям, то GCC обречен в отдаленной перспективе

I-Love-Microsoft ★★★★★ ()

исправьте, пожалуйста

проект уже мог незаметно пройти точку невозврата и компилятор FSF может умререть естественной смертью

на

проект уже мог незаметно пройти точку невозврата и FSF может умререть естественной смертью

x0r ★★★★★ ()
Ответ на: комментарий от anonymous

А так — каждый день похороны.

...каждый день веселье. :)

А по-моему есть ещё одна причина. Авторы новоделов громогласно «хоронят» старые варианты, чтобы успешнее пропихивать собственные творения. Скажем, леннарт хоронит sysVinit, чтобы пихать systemd, и т.д. Есть у меня такое мнение.

DeVliegendeHollander ★★ ()
Ответ на: комментарий от I-Love-Microsoft

Год какой? 10 лет LLVM, и все это время он обрекает и обрекает. В какой конкретно год он обойдет? В 2017? В 2030?

anonymous ()
Ответ на: комментарий от anonymous

behaviour -> behavior

Нифига, правильно и так, и так. То, что в тех.доках принято писать behavior и center вместо behaviour и centre, исключительно "заслуга" убогого амерского диалекта.

border-radius ()
Ответ на: комментарий от DeVliegendeHollander

Не исключаю такой возможности.

...каждый день веселье. :)

Во-во.

anonymous ()
Ответ на: комментарий от anonymous

Почему-то позабавило. Spellchecker отвалился?

Так вечно какие-то ошибки в моём английском.

quiet_readonly ★★★★ ()

в российских ВУЗах LLVM вытеснил MSIL

Так кто кого вытеснил?

unsigned ★★★ ()

:) как не ненавидят gcc, что он им плохого сделал ?

А вот что:

Открытое ПО свячески пытаются лишить основы, простого легковесного компилятора с языка Си, только вот вряд ли это получится сделать. Также не особо-то нужны go, с++11, с#.

Для системных целей gcc есть поддержка Си. С ней gcc лучше любых, к тому же едва шевелящихся монстров, справляется.

А вот судьба всего ООП, и языка go в том числе, как мне видится, в могиле, а все эти лозунги «gcc умри», это предсмертные стоны последнего отпрыска ООП - go.

perestoronin ★★ ()
Последнее исправление: perestoronin (всего исправлений: 1)
Ответ на: комментарий от unsigned

в российских ВУЗах LLVM вытеснил MSIL

Так кто кого вытеснил?

Раньше для наколенных компиляторов студенты использовали MSIL, сейчас предпочитают LLVM. Хотя для очень наколенных и завстрасдавать MSIL всё ещё пригождается, т.к. у него есть русскоязычная документация на MSDN, а читать сайты разработчиков на третьем курсе ещё не везде привыкли.

quiet_readonly ★★★★ ()
Ответ на: комментарий от DeVliegendeHollander

Я не писатель, если кто может меня поправить, то я буду только рад.

perestoronin ★★ ()

ОП заангажирован. В толксы.

goingUp ★★★★★ ()

как годно бурлит говно, а хомячки разносят вести

iddqd ()

ох уж эти разоблачители проекта корпоративных спецслужб codename GNU и культа личности Столлмана

Bad_ptr ★★★ ()
Последнее исправление: Bad_ptr (всего исправлений: 1)

Про интеграцию clang и Qt Creator - супер новость. Кстати, использование Qt Creator как IDE для Objective C предусматривается? В официальный Qt SDK эту интеграцию планируется включать?

NeoCode ()
Ответ на: комментарий от perestoronin

Жесть, больше не задерживай дыхание так долго.

buddhist ★★★★★ ()

Но по мере разрастания нити Diego Novillo из Google, хорошо зарекомендовавший себя в роли разработчика GCC, даже высказал опасения, что GCC уже прошёл точку невозврата и ему грозит естественная смерть.

Спасибо, Диего. Google тебе хорошо платит.

los_nikos ★★★★★ ()
Ответ на: комментарий от NeoCode

Кстати, использование Qt Creator как IDE для Objective C предусматривается?

Зачем он там? Есть же православный xcode.

anonymous ()

Уже можно хоронить?

cipher ★★★★★ ()
Ответ на: комментарий от anonymous

Чтоб было. Лично мне - просто для того, чтобы было удобно экспериментировать с этим языком (сейчас использую code::blocks для этого). Ну и тем кто реально разрабатывает под osx - тоже пригодится, почему бы и нет?

NeoCode ()
Ответ на: комментарий от NeoCode

Кстати, использование Qt Creator как IDE для Objective C предусматривается?

Со стороны редактора - да, работает автодополнение, подсветка и диагностика ошибок. Но по-хорошему нужна возможность открывать *.xcodeproj и перенос остальных фич с нативной модели на clang.

В официальный Qt SDK эту интеграцию планируется включать?

Нет, на 2013 год планов никаких: состояние плагина и самого clang не позволяет.

quiet_readonly ★★★★ ()
Последнее исправление: quiet_readonly (всего исправлений: 1)

Хорошо оформленная новость, даже мне, не специалисту, читать интересно.

TOPT ()
Ответ на: комментарий от perestoronin

проприетарных тролей разогнать и +2 чая этому господину =)

punya ★★ ()

добавляет неплохое автодополнение (в целом лучше, но в кое-чём хуже встроенного)

Так ведь clang по идее должен при автодополнении понимать код с точностью компилятора, почему он в чем-то оказывается хуже? Или речь про производительность?

pevzi ★★★★★ ()

По динамике развития очевидно, кто из них останется ведущим, а кому достанется скучная поддержка legacy и embedded.

note173 ★★★★★ ()
Ответ на: комментарий от NeoCode

Ну и тем кто реально разрабатывает под osx - тоже пригодится, почему бы и нет?

Отвечу немного подробнее насчёт ObjectiveC. Сейчас плагин использует смешанную модель кода: он просто подключает свои движки автодополнения, подсветки и подчёркивания ошибок в любезно подставленные интерфейсы, остальное по-прежнему обеспечивает встроенный парсер, из-за этого иногда возникает несоответствие. А текущие задачи таковы:

  • Создавать новые точки подключения и перегружать оставшиеся фичи
  • Использовать для личных проектов и устранять замеченные недостатки в уже перегруженных фичах

С Objective-C возникает проблема курицы и яйца. Поэтому вместо реализации нужного своими силами предпочтительнее другой план: сделать сборки под дистрибутивы линукса с чётко обрисованными плюсами и минусами (чтобы не было разочарований и дурной славы), а потом надеяться на правило 1% и продолжать посильную разработку.

quiet_readonly ★★★★ ()
Ответ на: комментарий от pevzi

Так ведь clang по идее должен при автодополнении понимать код с точностью компилятора, почему он в чем-то оказывается хуже? Или речь про производительность?

Абсолютно верно, точность очень хорошая. У clang к тому же отличная чувствительность к контексту кода и расстановка приоритетов для результатов. Но в QtCreator есть фичи, которые в clang пока ещё отсутствуют.

quiet_readonly ★★★★ ()
Ответ на: комментарий от perestoronin

ООП - go

Отсыпь, в go нет ни объектов, ни классов, ни наследования.

PolarFox ★★★★★ ()
Ответ на: комментарий от devl547

В какой версии смотрел? По мне, так LLVM/Clang 3.2 явно на уровне GCC 4.6.3.

iZEN ★★★★★ ()
Ответ на: комментарий от PolarFox

Отсыпь, в go нет ни объектов, ни классов, ни наследования.

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type ReadWriter interface {
    Reader
    Writer
}

П.С. прочитал на что это был ответ - да, называть Go ОО ЯП - это неправильно

wota ★★ ()
Последнее исправление: wota (всего исправлений: 2)
Ответ на: комментарий от wota

Как же тогда его назвать если не ОО ЯП, чтобы классифицировать? Хороше же go замаскировался под новые тренды :). А зачем тогда существует goop ?

Смотрю https://github.com/losalamos/goop/blob/master/goop_test.go

И вижу ... self Object ...

Это что - не ООП ? Как не замаскируется отпрыск ООП, его все равно видно.

perestoronin ★★ ()
Последнее исправление: perestoronin (всего исправлений: 1)
Ответ на: комментарий от anonymous

behaviour -> behavior


Почему-то позабавило. Spellchecker отвалился?

Британский английский кто-то там не любит. :)

Zubok ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.