Міжнародная канферэнцыя распрацоўнікаў і карыстальнікаў свабодных праграм

LibreOffice: как разрабатываются большие проекты?

Василий Меленчук, Минск, Belarus

LVEE 2017

LibreOffice is a well known open-source productivity suite with long and complex history. Thus nowadays we have rather huge (millions lines of code) and difficult in development and support project. How do we continue moving forward? Which tools and techniques do help us?

Введение / история

LibreOffice — проект с весьма длинной и причудливой историей. Всё начиналось в 1985 году с коммерческого текстового редактора StarWriter немецкой компании StarDivision. Позднее продукт расширился до StarOffice и весьма успешно продавался (по оценкам было продано 25 миллионов копий). В 1999 году компания была куплена Sun Microsystems и в 2000 году появилась open-source версия StarOffice — OpenOffice. Что не мешало компании Sun, а позднее и Oracle продавать расширенную версию StarOffice / Oracle OpenOffice.

В 2010 году появляется The Document Foundation, которая сделала собственный форк OpenOffice и с этого момента начинается развитие LibreOffice.

Текущее состояние

На данный момент проект имеет более 4 миллионов строк кода на C++ (а со сторонними библиотеками и сгенерированными исходниками — 8 миллионов). Помимо этого немалая часть кода написана на других языках. Ежемесячно в основную ветку кода вносится 1500-2000 изменений. Хотя проект разбит на более чем 200 отдельных модулей, они остаются весьма сильно сцеплены между собой.

Ожидаемо, что разработка и поддержка такого продукта является нетривиальной задачей.

Какие выходы из этой ситуации возможны и какие инструменты могут помочь? Пойдём по порядку:

Окружение

Для сборки LibreOffice требуется большое количество вспомогательных средств. В ряде случаев возможно обойтись apt-get build-dep libreoffice или подобными. Интересной альтернативой является использование LibreOffice Development Environment (lode), позволяющая просто клонировать соответствующий git-репозиторий и запустить скрипт, который всё самостоятельно сделает.

Компиляция

На «неподготовленном» компьютере компиляция проекта может занять от нескольких часов до нескольких десятков часов в случае компиляции под Windows (CygWin).

Для ускорения компиляции в Linux/UNIX первым делом используется ccache (compiler cache) — инструмент кеширующий результаты компиляции и значительно ускоряющий сборку проекта для файлов, которые не менялись. Стандартного размера кэша (обычно, 1Гб) категорически мало, и для комфортной работы кэш должен быть не менее 32Гб.

Весьма популярная возможность распараллеливания сборки проекта на несколько компьютеров при помощи distcc/icecream.

Работа с исходными текстами

Из-за достаточно большого объёма исходного кода многие IDE отказываются работать или же работают весьма неадекватно. Поэтому многие разработчики ограничиваются использованием vim/emacs. Тем не менее make имеет сценарии для генерации проектов для kdevelop, QTCreator, Visual Studio.

Для поиска и навигации по исходному коду неплохо подходит opengrok — веб-сервис, построенный на Lucene исключительно для этих целей. Для LibreOffice это http://opengrok.libreoffice.org/ Локально многие используют ctags.

Continuous Integration

Разумеется, первым делом, как и в любом современном проекте, Continuous Integration уже стандарт де-факто. В данном случае используется связка git+gerrit+jenkins. Но это только, разумеется мало.

Для «технического» прохождения code review требуется стабильная работа и прохождение тестов на 4 конфигурация: Linux (gcc), Linux (clang), Windows (msvc), MacOS (clang). Прочие платформы/конфигурации могут выступать в качестве т.н. Tinderbox: сторонний сервер, собирающий LibreOffice и предоставляющий результаты для включения в сводную таблицу результатов (http://tinderbox.libreoffice.org/MASTER/status.html).

На регулярной основе работают:

  • Статические анализаторы кода cppcheck и coverity
  • Средства для визуализации покрытия кода тестами lcov+gcov
  • Генератор документации doxygen

Интересной особенностью сборки LibreOffice является использование clang с дополнительными плагинами. На данный момент используется около 80 дополнительных плагинов (https://github.com/LibreOffice/core/tree/master/compilerplugins/clang), которые могут прервать сборку в случае обнаружения специфических для LibreOffice проблем или достаточно стандартных ошибок, которые почему-то игнорируются компиляторами. Например:

  • прямое сравнение чисел с плавающей точкой на равенство;
  • использование C-style приведения типов;
    *поиск неиспользуемых методов классов, методов, которые используются только внутри класса и в одном месте;
  • параметры методов, которые могут быть константными;
    и т.д.

bibisect (binary bisect)

Хороший и давно известный метод поиска регрессионных проблем — алгоритм бинарного поиска (метод деления отрезка пополам), который позволяет за весьма короткое время находить недавно появившиеся в программе баги. Git значительно облегчает эту задачу, см. git bisect. Но для большого объёма исходных текстов, как в LibreOffice, регулярная пересборка проекта может быть весьма продолжительной, серьёзно увеличивая затрачиваемое на поиск время. На помощь приходят специальные репозитории git, содержащие все (или с определённой гранулярностью) сборки проекта имеющие лишь одну цель: поиск регрессий с помощью git bisect. (https://wiki.documentfoundation.org/QA/Bibisect)

Abstract licensed under Creative Commons Attribution-ShareAlike 3.0 license

Назад