How To Help Developing Lazarus/ru

From Lazarus wiki
Jump to navigationJump to search

Deutsch (de) English (en) español (es) Bahasa Indonesia (id) 日本語 (ja) português (pt) русский (ru)

Прежде, чем участвовать в улучшении Lazarus

Прежде всего, запомните две вещи:

  • У вас должна быть последняя версия компилятора FreePascal (FPC) или его снимок SVN (т.е. будущая версия). Скачать можно по ссылке: скачать FreePascal.
  • Обязательно должна быть самая-самая последняя версия Lazarus из SVN (которую вы и будете помогать тестировать). Чтобы узнать, как ее получить, пройдите по ссылке: Как получить Lazarus из SVN.

В какой области применить свои возможности?

Итак, у вас есть самая свежая версия Lazarus и вам нетерпится чем-нибудь помочь проекту, но возникает вопрос: "а что, собственно, я могу сделать?".

Поиск и устранение ошибок

Если у вас не возникает каких-либо особенных проблем с Lazarus, но вам просто хочется чем-нибудь помочь, мы бы рекомендовали вам посмотреть список известных ошибок на баг-трекере, возможно, вы найдете ошибку, которую можете исправить. Команда разработчиков Lazarus выделила некоторые основные ошибки, которые необходимо устранить на пути к финальному релизу.

Документация

Lazarus нуждается в документации! Если у вас нет возможности исправлять ошибки в самой IDE - вы можете помочь в написании документации. Вы можете добавить информацию на эту и другие страницы, исправить ошибки в тексте и т.д. Перейдя по ссылкам редактор документации Lazarus и документация LCL, вы можете найти полезную информацию и список модулей, которые будут документированы. Во время работы IDE, нажмите F1 для получения справки. Вы будете направлены на страницу помощи, которая может быть пустой или незавершенной. Если вы обладаете достаточными знаниями в этом вопросе - заполните и улучшите ее!

Интегрированная среда разработки (IDE)

Смотрите следующие ссылки: продолжение IDE, на пути к финальному релизу.

Наборы визуальных компонентов (виджетов)

Набор виджетов - это "прослойка" между кодом библиотеки LCL, которая не зависит от целевой операционной системы, и собственно самой ОС. Для каждой поддерживаемой операционной системы модули библиотеки виджетов находятся в одной из поддиректорий C:\Lazarus\lcl\interfaces\ (в Windows). Следуя нижеприведенной инструкции, можно изменить набор виджетов. После внесения изменений в набор виджетов нет необходимости пересобирать все, включая саму IDE,как правило, можно протестировать эффект от изменений:

* Создайте свой тестовый проект (небольшую программу, которая содержала бы тестируемый код для измененного вами набора виджетов);
* Установите сочетания клавиш для 'Собрать Lazarus' и 'Собрать Lazarus с настройками' 
  (в IDE, перейдите Editor Options/Keymapping);
повторять
 * Настройте "Собрать Lazarus" так, чтобы собиралась только LCL 
  (в IDE, перейдите Tools/Configure "Собрать Lazarus");
 повторять
  * Внесите свои изменения в код набора виджетов;
  * Пересоберите Lazarus (в IDE, перейдите Tools/Build Lazarus 
    - это позволит пересобрать только LCL, а также выбранный набор виджетов);
  * Теперь можете откомпилировать и протестировать свой проект;
  * Запустите и отладьте проект;
 пока не будут найдены ошибки в измененном коде;
 * Перенастройте "Собрать Lazarus" на "Собрать все" 
   (в IDE, снова перейдите Tools/Configure "Собрать Lazarus");
 * Соберите Lazarus и протестируйте IDE;
пока не будет больше ошибок в ваших изменениях в IDE;
* Создайте патч (смотрите подробнее далее).

Как утвердить ваши изменения?

Вам будет необходимо создать патч (подробнее смотрите по ссылке создание патча. Предпочтительный способ показать свой патч разработчикам Lazarus - это создать описание на баг-трекере и прикрепить патч. Также можно прислать его по почте разработчикам (максимальный размер - 40 кБ) или на специальный почтовый ящик для патчей patch@lazarus.dommelstein.net (не забудьте в теме сообщения написать "patch", иначе письмо будет проигнорированно).

Борьба с регрессиями

Время от времени изменения в исходном коде Lazarus приводят к тому, что функции, работавшие ранее, перестают работать. Вы можете помочь узнать, начиная с какой версии начались проблемы. Этот процесс очень прост: Например, функция работала в сборке №1000, но не работает в №5000. Вы тестируете сборку №3000. Тестирование требует обновления кода из svn, пересборки LCL для нужного набора виджетов, и пересборки тестового приложения, которое использует нужную нам функцию, далее идет тестирование приложения. Если все работает - то тестируем сборки от 3000 до 5000, если нет - от 1000 до 3000, и так до тех пор, пока не найдем, в какой сборке закралась ошибка. Информация о том, в какой сборке появились проблемы, поможет быстрее и эффективней их решить, оставлять информацию можно на баг-трекере.

Чтобы проверить, какие данные соответствуют каждой сборке, можно использовать Lazarus svn browser (ViewVC). После того, как интервал между проверяемыми сборками сократится до какой-то небольшой цифры, например, 25, будет быстрее проверять изменения в сборках, используя ViewVC, это поможет выкинуть из проверки неподходящих кандидатов (те сборки, где наша неработающая функция не изменялась), это ускорит процесс.

Получить нужную сборку можно, используя команду: svn update -r <номер сборки>

Внимание! Если у вас медленное и ненадежное соединение с Интернет (как диал-ап или 3G), или ограничение трафика, то проверка разных сборок из SubVersion будет весьма медленным и дорогим процессом. Все сборки, которые вы проверяете, скачиваются из Интернет.

Эту проблему можно полностью устранить, если использовать Git для Lazarus, потому что вся история репозитория будет на вашем компьютере. Так что вы сможете проверить любую старую сборку без необходимости Интернет-соединения.

Автоматический поиск ошибок регрессии

SubVersion

Флориан написал небольшой скрипт для *nix, который может помочь автоматизировать процесс поиска регрессии. Скрипт называется searchrev.

Git зеркала

Git включает команду под названием bisect, которая помогает искать ошибки регрессии. Также есть поддержка автоматического тестирования. Вам необходимо будет создать небольшой тестовый пример и Git будет использовать этот пример, чтобы определить, есть ли в данной сборке ошибка или нет. С использованием автоматического тестирования ошибки регрессии находятся за считанные секунды. Для получения более подробной информации о команде git bisect, перейдите по ссылке Git - Руководство пользователя.

Все еще нужна помощь?

Если у вас есть какие-либо вопросы, вы можете задать их в следующих местах: