KBibTeX/Development/uk: Difference between revisions
(Created page with "=== Створення гілки для роботи над можливістю чи усування вади ===") |
(Created page with "=== Запис локальної гілки можливості чи вади ===") |
||
Line 92: | Line 92: | ||
{{Input|1=git branch --track feature/xxxx origin/master && git checkout feature/xxxx}} | {{Input|1=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, {{path|personalpublicclone}} is your personal, public Git repository where you want to push to. | 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, {{path|personalpublicclone}} is your personal, public Git repository where you want to push to. |
Revision as of 07:25, 30 September 2017
Різноманітні корисні ресурси
Нижче наведено посилання на інші сторінки інтернету та ресурси, які пов'язано із розробкоюю KBibTeX.
Отримання початкового коду програми
KBibTeX's sources are available through KDE's Git infrastructure, the repository's name is kbibtex. How to clone a Git repository is explained in the Git Recipes in TechBase. In short, run the following command in your terminal:
git clone git://anongit.kde.org/kbibtex
Переглянути код KBibTeX можна за допомогою сервера git KDE.
Гілки
Main development happens in the master branch (named master). It is an objective that this branch is functional and mostly stable, although it is not guaranteed. Use this branch to enjoy new features.
For releases, release branches are created. The naming scheme is kbibtex/versionnumber, where versionnumber may be something like 0.6. Actual releases are tagged commits ('tags') within such a branch, for example v0.5.1. There won't be branches for bug fix releases, e.g. no 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.
Збирання з коду
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 kbibtex/0.5) and KDE Frameworks 5-based builds (e.g. branch master). When compiling KBibTeX from inside of an IDE like KDevelop or Qt Creator, those settings have to be applied as well.
Запуск CMake
KBibTeX is configured using CMake. There are a few options relevant for the configuration of this project:
CMAKE_INSTALL_PREFIX:PATH
specifies the installation location. There are a number of choices available for this option:- The location of your KDE installation, for example /usr. The commands
kde4-config --prefix
(compiling for KDE4) orkf5-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. - A directory outside the package management's control, for example /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).
- 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.
- The location of your KDE installation, for example /usr. The commands
CMAKE_BUILD_TYPE
determines the amount of debug information included in the final code. Regular users may set it torelease
, developers todebug
, and for step-by-step debuggingdebugfull
works best. All available options are discussed in the CMake documentation in TechBase.
A complete example looks like this:
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)
To make use of of ninja, the cmake
statement above has to include the argument -GNinja
. Combining both cmake and ninja may look like this:
cmake -GNinja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/usr -DCMAKE_BUILD_TYPE=debug ../kbibtex && ninja
Встановлення
KBibTeX uses KDE's KParts technology, which requires you to install some libraries. KBibTeX may not run properly if the following steps are omitted.
Running
make install
will install KBibTeX into the directory as specified as installation prefix earlier.
Unless the installation prefix equals the KDE install directory, the following environment variables have to be specified:
- Only for KDE4: Set variable
KDEDIRS
to include the KDE installation directory and KBibTeX's installation directory, for example /usr:/tmp/usr - 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/ - Set variable
LD_LIBRARY_PATH
to the library directory inside KBibTeX's installation directory, for example /tmp/usr/lib64 - 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.
Now KBibTeX can be started, like shown in this example:
/tmp/usr/bin/kbibtex
Настанови з роботи у git
A number of pages in TechBase, UserBase, and Community discuss using Git for source code management. This section shows some examples how Git is used for 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.
To publish you changes, use a command like this:
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 git@git.kde.org:clones/kbibtex/NAME/kbibtex # run once git fetch someonespublicclone feature/xxxx && git checkout feature/xxxx # every time to get updates git remote rm someonespublicclone && git checkout master && git branch -D feature/xxxx # to erase branch
Create Release Branches and Tags
To create a release branch from master and push it to origin, run
git checkout -b kbibtex/0.6 master && git push origin kbibtex/0.6
To tag a release in a release branch, run the following commands:
git checkout kbibtex/0.6 # be in right branch git pull --ff-only # get latest changes from origin git status # just check that everything is ok git tag -s -u GPGKEY -m "Tagging 0.6" v0.6 # actual tagging, GnuPG signed git push --tags # explicitly push tag to origin
Creating a Release
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
Fetching documentation and translation files is the most time-consuming part of this process.
Detached cryptographic hashes can be created and signed like this:
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