KBibTeX/Development/uk: Difference between revisions

From KDE UserBase Wiki
(Updating to match new version of source page)
(Created page with "# Встановіть для змінної <code>LD_LIBRARY_PATH</code> значення, яке вказуватиме на каталог бібліотек у катал...")
(10 intermediate revisions by the same user not shown)
Line 18: Line 18:
* [https://scan.coverity.com/projects/kbibtex Сканування покриття коду]
* [https://scan.coverity.com/projects/kbibtex Сканування покриття коду]


* [https://t-fischer.dreamwidth.org/tag/kbibtex Blog postings on KBibTeX]
* [https://t-fischer.dreamwidth.org/tag/kbibtex Блог, який присвячено KBibTeX]


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


For releases, ''release branches'' are created. The naming scheme is {{path|kbibtex/}}''versionnumber'', where ''versionnumber'' may be something like {{path|0.6}}. Actual releases are tagged commits ('tags') within such a branch, for example {{path|v0.5.1}}. There won't be branches for bug fix releases, e.g. no {{path|kbibtex/0.6.1}}.
Для випусків створюються ''гілки випусків''. Назви для цих гілок формуються таким чином: {{path|kbibtex/}}''номер версії'', де вмістом рядка ''номер версії'' може бути щось таке: {{path|0.6}}. Самі випуски у такій гілці визначаються позначеними внесками («мітками»), наприклад {{path|v0.5.1}}. Гілок для випусків із виправленнями вад не створюється, наприклад, немає гілки {{path|kbibtex/0.6.1}}.


For bugs or features that require multiple commits and where individual commits may break {{path|master}} or a release branch, so-called ''feature branches'' are used. These branches are supposed to track {{path|master}} (typical for features) or a release branch (typical for bugs). Branches for bugs are meant to be merged into the release branch where the bug was reported for as well as into the master branch (for future releases). Feature branches are merged into the master branch, in selected cases into releases branches where no release has been tagged yet, and only in rare cases back-ported to release branches with published releases. An example for a feature branch would be {{path|feature/zotero}}, which may contain the code for an improved Zotero support. Names for bug report-related branches are {{path|bugs/}}''bugsystemnumber'' (for example {{path|bugs/kde338375}}) , where ''bugsystem'' would be {{path|kde}} or the name of a Linux distribution and ''number'' the actual bug number. Feature branches start with {{path|feature/}} followed by a short descriptive name for this feature (all lowercase, no spaces). Merged branches will be delete after some time.
For bugs or features that require multiple commits and where individual commits may break {{path|master}} or a release branch, so-called ''feature branches'' are used. These branches are supposed to track {{path|master}} (typical for features) or a release branch (typical for bugs). Branches for bugs are meant to be merged into the release branch where the bug was reported for as well as into the master branch (for future releases). Feature branches are merged into the master branch, in selected cases into releases branches where no release has been tagged yet, and only in rare cases back-ported to release branches with published releases. An example for a feature branch would be {{path|feature/zotero}}, which may contain the code for an improved Zotero support. Names for bug report-related branches are {{path|bugs/}}''bugsystemnumber'' (for example {{path|bugs/kde338375}}) , where ''bugsystem'' would be {{path|kde}} or the name of a Linux distribution and ''number'' the actual bug number. Feature branches start with {{path|feature/}} followed by a short descriptive name for this feature (all lowercase, no spaces). Merged branches will be delete after some time.
Line 38: Line 38:
== Збирання з коду ==
== Збирання з коду ==


The following instructions provide information how to compile KBibTeX on the command line. Instructions are similar but differ slightly between KDE4-based builds (e.g. branch {{path|kbibtex/0.5}}) and KDE Frameworks 5-based builds (e.g. branch {{path|master}}). When compiling KBibTeX from inside of an IDE like KDevelop or Qt Creator, those settings have to be applied as well.
Наведені нижче настанови стосуються збирання KBibTeX з командного рядка. Настанови для збирання на основі KDE4 (наприклад, для гілки {{path|kbibtex/0.5}}) і на основі KDE Frameworks 5 (наприклад, для гілки {{path|master}}) дещо відрізняються. Якщо ви збиратимете KBibTeX з комплексного середовища для розробки, наприклад KDevelop або Qt Creator, слід також застосувати вказані нижче параметри.


=== Запуск CMake ===
=== Запуск CMake ===
Line 46: Line 46:
# <code>CMAKE_INSTALL_PREFIX:PATH</code> визначає місце, де зберігатиметься зібрана програма. Існує декілька варіантів значень для цього параметра:
# <code>CMAKE_INSTALL_PREFIX:PATH</code> визначає місце, де зберігатиметься зібрана програма. Існує декілька варіантів значень для цього параметра:
## The location of your KDE installation, for example {{Path|/usr}}. The commands <code>kde4-config --prefix</code> (compiling for KDE4) or <code>kf5-config --prefix</code> (compiling for KDE Frameworks 5) print this location. Requires root permissions (e. g. via sudo). Caution: This choice will interfere with the package management.
## The location of your KDE installation, for example {{Path|/usr}}. The commands <code>kde4-config --prefix</code> (compiling for KDE4) or <code>kf5-config --prefix</code> (compiling for KDE Frameworks 5) print this location. Requires root permissions (e. g. via sudo). Caution: This choice will interfere with the package management.
## 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. Requires root permissions (e. g. via sudo).
## Каталог поза каталогами системи керування пакунками, наприклад {{Path|/usr/local}}. Потребує встановлення певних змінних середовища, пояснення щодо яких наведено нижче. Встановлена до цього каталогу версія зможе пережити перезавантаження системи і буде доступною для усіх користувачів. Потребує прав доступу адміністратора (ці права можна отримати за допомогою, наприклад, команди sudo).
## A user-writable directory like {{Path|/tmp/usr}} or {{Path|~/usr}}. Similar to above choice, it requires setting some environment variables, but no root permissions. Many distributions are configured to clean {{Path|/tmp}} on reboot.
## A user-writable directory like {{Path|/tmp/usr}} or {{Path|~/usr}}. Similar to above choice, it requires setting some environment variables, but no root permissions. Many distributions are configured to clean {{Path|/tmp}} on reboot.
# <code>CMAKE_BUILD_TYPE</code> determines the amount of debug information included in the final code. Regular users may set it to <code>release</code>, developers to <code>debug</code>, and for step-by-step debugging <code>debugfull</code> works best. All available options are discussed in the [https://techbase.kde.org/Development/CMake/Addons_for_KDE#Buildtypes CMake documentation in TechBase].
# <code>CMAKE_BUILD_TYPE</code> determines the amount of debug information included in the final code. Regular users may set it to <code>release</code>, developers to <code>debug</code>, and for step-by-step debugging <code>debugfull</code> works best. All available options are discussed in the [https://techbase.kde.org/Development/CMake/Addons_for_KDE#Buildtypes CMake documentation in TechBase].
Line 59: Line 59:
{{Input|nice -n 16 make -j$(nproc)}}
{{Input|nice -n 16 make -j$(nproc)}}


To make use of of [https://ninja-build.org/ ninja], the <code>cmake</code> statement above has to include the argument <code>-GNinja</code>. Combining both cmake and ninja may look like this:
Для використання [https://ninja-build.org/ ninja] наведена вище інструкція <code>cmake</code> має містити аргумент <code>-GNinja</code>. Поєднання cmake і ninja може виглядати так:


{{Input|1=cmake -GNinja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/usr -DCMAKE_BUILD_TYPE=debug ../kbibtex && ninja}}
{{Input|1=cmake -GNinja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/usr -DCMAKE_BUILD_TYPE=debug ../kbibtex && ninja}}
Line 73: Line 73:
Якщо як префікс встановлення не було вказано каталог, куди встановлено інші пакунки KDE, слід визначити такі змінні середовища:
Якщо як префікс встановлення не було вказано каталог, куди встановлено інші пакунки KDE, слід визначити такі змінні середовища:


# '''Only for KDE4''': Set variable <code>KDEDIRS</code> to include the KDE installation directory and KBibTeX's installation directory, for example {{Path|/usr:/tmp/usr}}
# '''Лише для KDE4''': встановіть таке значення змінної <code>KDEDIRS</code>, щоб до нього було включено каталог встановлення KDE і каталог встановлення KBibTeX, наприклад {{Path|/usr:/tmp/usr}}
# '''Only for KF5''': Set variable <code>QT_PLUGIN_PATH</code> to include the plugin directory inside the library directory of KBibTeX's installation directory, for example {{Path|/usr/lib/plugins:/usr/lib/qt5/plugins:/tmp/usr/lib64/plugins/}}
# '''Only for KF5''': Set variable <code>QT_PLUGIN_PATH</code> to include the plugin directory inside the library directory of KBibTeX's installation directory, for example {{Path|/usr/lib/plugins:/usr/lib/qt5/plugins:/tmp/usr/lib64/plugins/}}
# Set variable <code>LD_LIBRARY_PATH</code> to the library directory inside KBibTeX's installation directory, for example {{Path|/tmp/usr/lib64}}
# Встановіть для змінної <code>LD_LIBRARY_PATH</code> значення, яке вказуватиме на каталог бібліотек у каталозі встановлення KBibTeX, наприклад, {{Path|/tmp/usr/lib64}}
# Set variable <code>XDG_DATA_DIRS</code> to include the shared data directories of the KDE installation directory, KBibTeX's installation directory, and other relevant prefixes, for example {{Path|/usr/share:/usr/local/share:/tmp/usr/share}}
# Set variable <code>XDG_DATA_DIRS</code> to include the shared data directories of the KDE installation directory, KBibTeX's installation directory, and other relevant prefixes, for example {{Path|/usr/share:/usr/local/share:/tmp/usr/share}}


Run <code>kbuildsycoca4</code> (KDE4) or <code>kbuildsycoca5</code> (KDE Frameworks 5) to make the KDE subsystem aware of the new libraries.
Run <code>kbuildsycoca4</code> (KDE4) or <code>kbuildsycoca5</code> (KDE Frameworks 5) to make the KDE subsystem aware of the new libraries.


Now KBibTeX can be started, like shown in this example:
Тепер KBibTeX можна запустити, як це показано у прикладі:


{{Input|/tmp/usr/bin/kbibtex}}
{{Input|/tmp/usr/bin/kbibtex}}
Line 86: Line 86:
== Настанови з роботи у git ==
== Настанови з роботи у git ==


A number of pages in [https://techbase.kde.org TechBase], [https://userbase.kde.org UserBase], and [https://community.kde.org Community] discuss using Git for source code management. This section shows some examples how Git is used for KBibTeX.
Обговоренню використання git для керування початковим кодом програм присвячено багато сторінок [https://techbase.kde.org TechBase], [https://userbase.kde.org UserBase] та [https://community.kde.org Community]. У цьому розділі наведено декілька прикладів використання git у контексті KBibTeX.


=== Створення гілки для роботи над можливістю чи усування вади ===
=== Створення гілки для роботи над можливістю чи усування вади ===
Line 104: Line 104:
Others can add your repository to their local clone of KBibTeX's git and clone your branch (assuming in this example it is located on KDE's Git server):
Others can add your repository to their local clone of KBibTeX's git and clone your branch (assuming in this example it is located on KDE's Git server):


{{Input|git remote add someonespublicclone [email protected]:clones/kbibtex/NAME/kbibtex # run once
{{Input|git remote add someonespublicclone [email protected]:clones/kbibtex/NAME/kbibtex # цю команду слід віддати один раз
git fetch someonespublicclone feature/xxxx && git checkout feature/xxxx # every time to get updates
git fetch someonespublicclone feature/xxxx && git checkout feature/xxxx # під час кожного сеансу отримання оновлень
git remote rm someonespublicclone && git checkout master && git branch -D feature/xxxx # to erase branch}}
git remote rm someonespublicclone && git checkout master && git branch -D feature/xxxx # команда, щоб вилучити гілку}}


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


{{Input|git checkout kbibtex/0.6 # be in right branch
{{Input|git checkout kbibtex/0.6 # перейти до відповідної гілки
git pull --ff-only # get latest changes from origin
git pull --ff-only # отримати найсвіжіші оновлення з початкового сховища
git status # just check that everything is ok
git status # перевірити, чи все гаразд
git tag -s -u GPGKEY -m "Tagging 0.6" v0.6 # actual tagging, GnuPG signed
git tag -s -u GPGKEY -m "Tagging 0.6" v0.6 # actual tagging, GnuPG signed
git push --tags # explicitly push tag to origin}}
git push --tags # явним чином надіслати мітку до початкового сховища}}


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

Revision as of 20:31, 9 November 2017

Other languages:

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

Нижче наведено посилання на інші сторінки інтернету та ресурси, які пов'язано із розробкоюю 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.

For bugs or features that require multiple commits and where individual commits may break master or a release branch, so-called feature branches are used. These branches are supposed to track master (typical for features) or a release branch (typical for bugs). Branches for bugs are meant to be merged into the release branch where the bug was reported for as well as into the master branch (for future releases). Feature branches are merged into the master branch, in selected cases into releases branches where no release has been tagged yet, and only in rare cases back-ported to release branches with published releases. An example for a feature branch would be feature/zotero, which may contain the code for an improved Zotero support. Names for bug report-related branches are bugs/bugsystemnumber (for example bugs/kde338375) , where bugsystem would be kde or the name of a Linux distribution and number the actual bug number. Feature branches start with feature/ followed by a short descriptive name for this feature (all lowercase, no spaces). Merged branches will be delete after some time.

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

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

Запуск CMake

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

  1. CMAKE_INSTALL_PREFIX:PATH визначає місце, де зберігатиметься зібрана програма. Існує декілька варіантів значень для цього параметра:
    1. The location of your KDE installation, for example /usr. The commands kde4-config --prefix (compiling for KDE4) or kf5-config --prefix (compiling for KDE Frameworks 5) print this location. Requires root permissions (e. g. via sudo). Caution: This choice will interfere with the package management.
    2. Каталог поза каталогами системи керування пакунками, наприклад /usr/local. Потребує встановлення певних змінних середовища, пояснення щодо яких наведено нижче. Встановлена до цього каталогу версія зможе пережити перезавантаження системи і буде доступною для усіх користувачів. Потребує прав доступу адміністратора (ці права можна отримати за допомогою, наприклад, команди sudo).
    3. A user-writable directory like /tmp/usr or ~/usr. Similar to above choice, it requires setting some environment variables, but no root permissions. Many distributions are configured to clean /tmp on reboot.
  2. CMAKE_BUILD_TYPE determines the amount of debug information included in the final code. Regular users may set it to release, developers to debug, and for step-by-step debugging debugfull works best. All available options are discussed in the CMake documentation in TechBase.

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

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

Компіляція

GNU Make is the default choice for source code compilation. The number of parallel processes should be specified to shorten the time to finish on multi-core systems. The priority of the compilation tasks may get reduced. 

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, якщо не виконаєте настанови щодо наступних кроків.

Команда 

make install

встановить KBibTeX до каталогу, який було вказано як префікс встановлення раніше.

Якщо як префікс встановлення не було вказано каталог, куди встановлено інші пакунки KDE, слід визначити такі змінні середовища:

  1. Лише для KDE4: встановіть таке значення змінної KDEDIRS, щоб до нього було включено каталог встановлення KDE і каталог встановлення KBibTeX, наприклад /usr:/tmp/usr
  2. Only for KF5: Set variable QT_PLUGIN_PATH to include the plugin directory inside the library directory of KBibTeX's installation directory, for example /usr/lib/plugins:/usr/lib/qt5/plugins:/tmp/usr/lib64/plugins/
  3. Встановіть для змінної LD_LIBRARY_PATH значення, яке вказуватиме на каталог бібліотек у каталозі встановлення KBibTeX, наприклад, /tmp/usr/lib64
  4. Set variable XDG_DATA_DIRS to include the shared data directories of the KDE installation directory, KBibTeX's installation directory, and other relevant prefixes, for example /usr/share:/usr/local/share:/tmp/usr/share

Run kbuildsycoca4 (KDE4) or kbuildsycoca5 (KDE Frameworks 5) to make the KDE subsystem aware of the new libraries.

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

/tmp/usr/bin/kbibtex

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

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

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

In below example, replace xxxx with a short and concise name for a feature to be developed (as discussed above). Branches for bugs are created similarly, but follow the scheme bugs/kdeNNNN, where NNNN is the bug number in KDE's bug tracker. Bugs in other bug trackers such as Gna! or your distribution may use a different prefix such as bugs/gnaNNNN or bugs/gentooNNNN. 

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

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

To minimize polluting the official KBibTeX repository or when you do not have write access, you may push your local branches to another Git repository to allow others to inspect your changes. In below example, personalpublicclone is your personal, public Git repository where you want to push to.

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

git push personalpublicclone feature/xxxx:feature/xxxx

Others can add your repository to their local clone of KBibTeX's git and clone your branch (assuming in this example it is located on KDE's Git server): 

git remote add someonespublicclone [email protected]: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 # явним чином надіслати мітку до початкового сховища

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

Information

This section describes how to create releases based on KDE4 (kdelibs4). It will not work for KDE Frameworks 5.

To create a release, use the Ruby scripts from the git.kde.org:releaseme.git repository. KBibTeX's package generation is configured through files kbibtex.rb and kbibtexrc. Configure those files or invoke kbibtex.rb with the correct arguments, such as: 

./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
Retrieved from "https://userbase.kde.org/index.php?title=KBibTeX/Development/uk&oldid=386010"