Difference between revisions of "KBibTeX/Development/uk"

Jump to: navigation, search
Line 46: Line 46:
 
# <code>CMAKE_INSTALL_PREFIX:PATH</code> визначає місце, де зберігатиметься зібрана програма. Існує декілька варіантів значень для цього параметра:
 
# <code>CMAKE_INSTALL_PREFIX:PATH</code> визначає місце, де зберігатиметься зібрана програма. Існує декілька варіантів значень для цього параметра:
 
## Каталог, куди встановлено вашу версію KDE, наприклад {{Path|/usr}}. Команди <code>kde4-config --prefix</code> (збирання для KDE4) or <code>kf5-config --prefix</code> (збирання для KDE Frameworks 5) виводять цю адресу. Потрібні права доступу адміністратора (наприклад, за допомогоюо sudo). Попередження: цей варіант не варто використовувати разом із системою для керування пакунками.
 
## Каталог, куди встановлено вашу версію KDE, наприклад {{Path|/usr}}. Команди <code>kde4-config --prefix</code> (збирання для KDE4) or <code>kf5-config --prefix</code> (збирання для KDE Frameworks 5) виводять цю адресу. Потрібні права доступу адміністратора (наприклад, за допомогоюо sudo). Попередження: цей варіант не варто використовувати разом із системою для керування пакунками.
## A directory outside the package management's control, for example {{Path|/usr/local}}. Requires setting some environment variables as explained below. This installation stays available across reboots and is available to all users. Picking this option most likely will require root permissions (e. g. via sudo) for the actual installation.
+
## Каталог поза каталогами системи керування пакунками, наприклад {{Path|/usr/local}}. Потребує встановлення певних змінних середовища, пояснення щодо яких наведено нижче. Встановлена до цього каталогу версія зможе пережити перезавантаження системи і буде доступною для усіх користувачів. Потребує прав доступу адміністратора (ці права можна отримати за допомогою, наприклад, команди sudo).
 
## Доступний для запису користувачам каталог, наприклад {{Path|/tmp/usr}} або {{Path|~/usr}}. Подібний до попереднього варіант, потребує встановлення змінних середовища, але не потребує прав доступу адміністратора. У багатьох дистрибутивах налаштовано спорожнення каталогу {{Path|/tmp}} під час перезавантаження системи.
 
## Доступний для запису користувачам каталог, наприклад {{Path|/tmp/usr}} або {{Path|~/usr}}. Подібний до попереднього варіант, потребує встановлення змінних середовища, але не потребує прав доступу адміністратора. У багатьох дистрибутивах налаштовано спорожнення каталогу {{Path|/tmp}} під час перезавантаження системи.
 
# <code>CMAKE_BUILD_TYPE</code> визначає обсяг діагностичних даних, які буде включено до остаточного коду. Звичайним користувачам варто встановити значення <code>release</code>, розробникам — <code>debug</code>, а для покрокової діагностики найкращим варіантом є <code>debugfull</code>. Докладний опис усіх доступних варіантів наведено у [https://techbase.kde.org/Development/CMake/Addons_for_KDE#Buildtypes документації з CMake на TechBase].
 
# <code>CMAKE_BUILD_TYPE</code> визначає обсяг діагностичних даних, які буде включено до остаточного коду. Звичайним користувачам варто встановити значення <code>release</code>, розробникам — <code>debug</code>, а для покрокової діагностики найкращим варіантом є <code>debugfull</code>. Докладний опис усіх доступних варіантів наведено у [https://techbase.kde.org/Development/CMake/Addons_for_KDE#Buildtypes документації з CMake на TechBase].

Revision as of 09:29, 6 May 2018

Other languages:
English • ‎українська

Різноманітні корисні ресурси

Нижче наведено посилання на інші сторінки інтернету та ресурси, які пов'язано із розробкоюю KBibTeX.

Отримання початкового коду програми

Початкові коди KBibTeX доступні з інфраструктури Git KDE, назва сховища — kbibtex. Спосіб клонування сховища Git описано у рецептах щодо Git на TechBase. Якщо коротко, слід віддати таку команду у терміналі:

git clone git://anongit.kde.org/kbibtex

Переглянути код KBibTeX можна за допомогою сервера git KDE.

Гілки

Основна розробка відбувається у «основній гілці» (має назву master). Розробники намагаються зробити так, щоб ця гілка була працездатною і майже стабільною, але її стабільність не гарантовано. Ви можете скористатися цією гілкою для того, щоб мати доступ до найновіших можливостей.

Для випусків створюються гілки випусків. Назви для цих гілок формуються таким чином: kbibtex/номер версії, де вмістом рядка номер версії може бути щось таке: 0.6. Самі випуски у такій гілці визначаються позначеними внесками («мітками»), наприклад v0.5.1. Гілок для випусків із виправленнями вад не створюється, наприклад, немає гілки kbibtex/0.6.1.

Для виправлення вад або реалізації можливостей, які потребують декількох внесків до коду і для яких окремі внески можуть призвести до непрацездатності коду у master або гілці випуску, використовуються так звані «гілки можливостей». Ці гілки має бути синхронізовано з master (типово для можливостей) або гілкою випуску (типово для виправлення вад). Гілки для виправлення вад призначено для злиття з гілкою випуску, щодо якої було створено повідомлення щодо вади, і з гілкою master (для майбутніх випусків). Гілки можливостей зливаються з гілкою master, у вибраних випадках із гілками випусків, де ще немає жодної мітки випуску, і лише іноді зворотно портуються до гілок випусків, де є мітки оприлюднених випусків програми. Прикладом гілки можливостей є гілка feature/zotero, у якій міститься код покращеної підтримки Zotero. Назвами гілок, які пов'язано зі звітами щодо вад, є bugs/'номер у системі стеження за вадами (наприклад bugs/kde338375) , де системою стеження за вадами може бути kde або назва дистрибутива Linux, а номером є номер повідомлення щодо вади. Назви гілок можливостей мають починатися з feature/, за яким має бути коротка описова назва можливості (малими літерами, без пробілів). Об'єднані гілки за деякий час буде вилучено.

Збирання з коду

Наведені нижче настанови стосуються збирання KBibTeX з командного рядка. Настанови для збирання на основі KDE4 (наприклад, для гілки kbibtex/0.5) і на основі KDE Frameworks 5 (наприклад, для гілки master) дещо відрізняються. Якщо ви збиратимете KBibTeX з комплексного середовища для розробки, наприклад KDevelop або Qt Creator, слід також застосувати вказані нижче параметри.

Запуск CMake

Збирання KBibTeX налаштовується за допомогою CMake. Для збирання проекту передбачено декілька параметрів:

  1. CMAKE_INSTALL_PREFIX:PATH визначає місце, де зберігатиметься зібрана програма. Існує декілька варіантів значень для цього параметра:
    1. Каталог, куди встановлено вашу версію KDE, наприклад /usr. Команди kde4-config --prefix (збирання для KDE4) or kf5-config --prefix (збирання для KDE Frameworks 5) виводять цю адресу. Потрібні права доступу адміністратора (наприклад, за допомогоюо sudo). Попередження: цей варіант не варто використовувати разом із системою для керування пакунками.
    2. Каталог поза каталогами системи керування пакунками, наприклад /usr/local. Потребує встановлення певних змінних середовища, пояснення щодо яких наведено нижче. Встановлена до цього каталогу версія зможе пережити перезавантаження системи і буде доступною для усіх користувачів. Потребує прав доступу адміністратора (ці права можна отримати за допомогою, наприклад, команди sudo).
    3. Доступний для запису користувачам каталог, наприклад /tmp/usr або ~/usr. Подібний до попереднього варіант, потребує встановлення змінних середовища, але не потребує прав доступу адміністратора. У багатьох дистрибутивах налаштовано спорожнення каталогу /tmp під час перезавантаження системи.
  2. CMAKE_BUILD_TYPE визначає обсяг діагностичних даних, які буде включено до остаточного коду. Звичайним користувачам варто встановити значення release, розробникам — debug, а для покрокової діагностики найкращим варіантом є debugfull. Докладний опис усіх доступних варіантів наведено у документації з CMake на TechBase.

Приклад команди повністю:

cmake -DCMAKE_INSTALL_PREFIX:PATH=/tmp/usr -DCMAKE_BUILD_TYPE=debug ../kbibtex

Компіляція

GNU Make є типовим вибором для збирання початкових кодів. Для пришвидшення збирання коду на багатопроцесорних системах слід вказати кількість паралельних процесів збирання. Пріоритетність завдань зі збирання варто робити дещо нижчою за типову.

nice -n 16 make -j$(nproc)

Для використання ninja наведена вище інструкція cmake має містити аргумент -GNinja. Поєднання cmake і ninja може виглядати так:

cmake -GNinja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/usr -DCMAKE_BUILD_TYPE=debug ../kbibtex && ninja

Встановлення

У KBibTeX використано технологію KDE KParts, для реалізації якої вам доведеться встановити деякі бібліотеки. Ви не зможете належним чином користуватися KBibTeX, якщо не виконаєте настанови щодо наступних кроків.

Running

make install

will install KBibTeX into the directory as specified as installation prefix earlier. Depending on your choice of installation prefix, this statement has to be run with sudo or alike.

Unless the installation prefix equals the KDE install directory, the following environment variables have to be specified. You may set the variables temporarily in an active shell session, permanently setting them in your shell's configuration, or create a small shell script that both sets those variables and then launches your custom KBibTeX installation.

  1. Лише для KDE4: встановіть таке значення змінної KDEDIRS, щоб до нього було включено каталог встановлення KDE і каталог встановлення KBibTeX, наприклад /usr:/tmp/usr
  2. Лише для KF5: встановіть значення змінної середовища QT_PLUGIN_PATH так, щоб до неї було включено каталог додатків у каталозі бібліотеки каталогу, куди встановлено KBibTeX, наприклад /usr/lib/plugins:/usr/lib/qt5/plugins:/tmp/usr/lib64/plugins/
  3. Встановіть для змінної LD_LIBRARY_PATH значення, яке вказуватиме на каталог бібліотек у каталозі встановлення KBibTeX, наприклад, /tmp/usr/lib64
  4. Встановіть для змінної XDG_DATA_DIRS значення так, щоб до нього було включено каталоги спільних даних каталогу, до якого встановлено KDE, каталог встановлення KBibTeX та інші відповідні префікси, наприклад /usr/share:/usr/local/share:/tmp/usr/share

Запустіть kbuildsycoca4 (KDE4) або kbuildsycoca5 (KDE Frameworks 5), щоб повідомити підсистему KDE про появу нових бібліотек.

Тепер KBibTeX можна запустити, як це показано у прикладі:

/tmp/usr/bin/kbibtex

Настанови з роботи у git

Обговоренню використання git для керування початковим кодом програм присвячено багато сторінок TechBase, UserBase та Community. У цьому розділі наведено декілька прикладів використання git у контексті KBibTeX.

Створення гілки для роботи над можливістю чи усування вади

У наведеномуни ничже прикладі замініть xxxx короткою і точною назвою можливості, яка розроблятиметься (як це обговорювалося вище). Гілки для виправлення вад створюються аналогічним чином, але для їхніх назв використовується схема bugs/kdeNNNN, де NNNN — номер вади у системі стеження за вадами KDE. Для вад у інших системах стеження за вадами, зокрема Gna! або системі стеження за вадами у вашому дистрибутивів, використовується інший префікс, наприклад bugs/gnaNNNN або bugs/gentooNNNN.

git branch --track feature/xxxx origin/master && git checkout feature/xxxx

Запис локальної гілки можливості чи вади

З метою мінімізації захаращення офіційного сховища KBibTeX або для випадків, коли у вас немає права запису до сховища, ви можете записувати ваші локальні гілки до іншого сховища Git, щоб інші розробники змогли вивчити внесені вами зміни. У наведеному нижче прикладі personalpublicclone є вашим власним відкритим сховищем Git, до якого ви можете записувати дані.

Для оприлюднення внесених вами змін скористайтеся такою командою:

git push personalpublicclone feature/xxxx:feature/xxxx

Інші розробники зможуть додати ваше сховище до власного локального клону сховища git KBibTeX, клонувати вашу гілку (у нашому прикладі ми припускаємо, що гілку розташовано на серверіgit KDE):

git remote add someonespublicclone git@git.kde.org:clones/kbibtex/NAME/kbibtex # цю команду слід віддати один раз
git fetch someonespublicclone feature/xxxx && git checkout feature/xxxx # під час кожного сеансу отримання оновлень
git remote rm someonespublicclone && git checkout master && git branch -D feature/xxxx # команда, щоб вилучити гілку

Створення гілок і міток випусків

Для створення гілки випуску з master і надсилання її до origin віддайте такі команди:

git checkout -b kbibtex/0.6 master && git push origin kbibtex/0.6

Для створення випуску у гілці випуску віддайте такі команди:

git checkout kbibtex/0.6 # перейти до відповідної гілки
git pull --ff-only # отримати найсвіжіші оновлення з початкового сховища
git status # перевірити, чи все гаразд
git tag -s -u GPGKEY -m "Tagging 0.6" v0.6 # actual tagging, GnuPG signed
git push --tags # явним чином надіслати мітку до початкового сховища

Створення випуску

Dialog-information.png
 
Інформація
У цьому розділі описано процес створення випусків на основі KDE4 (kdelibs4). Наведені інструкції не працюватимуть для KDE Frameworks 5.


Для створення випуску скористайтеся скриптами мовою Ruby зі сховища git.kde.org:releaseme.git. Створення пакунка KBibTeX налаштовується за допомогою файлів kbibtex.rb і kbibtexrc. Виконайте редагування цих файлів і викличте kbibtex.rb із відповідними аргументами, ось так:

./kbibtex.rb --src=file:///${HOME}/git/kbibtex --version=0.6.0 --no-doc --no-l10n

Отримання файлів перекладу інтерфейсу і документації є найдовшим етапом у цьому процесі.

Криптографічні хеші можна створити і записати ось так:

sha512sum kbibtex-0.6.0.tar.xz >kbibtex-0.6.0.tar.xz.sha512
gpg --default-key GPGKEY --output kbibtex-0.6.0.tar.xz.sha512.asc --detach-sign --armor kbibtex-0.6.0.tar.xz.sha512
gpg --default-key GPGKEY --output kbibtex-0.6.0.tar.xz.asc --detach-sign --armor kbibtex-0.6.0.tar.xz

Content is available under Creative Commons License SA 4.0 unless otherwise noted.