В прошедший вторник в список рассылки 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
DEFINES += CLANG_INDEXING
>>> Подробности
