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

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)