KGeoTag: Difference between revisions

From KDE Community Wiki
(Added additional files that have to be present)
Line 51: Line 51:
=== Running the compiled sources ===
=== Running the compiled sources ===


You don't have to install KGeoTag (neither system-wide, nor locally) to be able to run it. The executable file will end up at <code>bin/kgeotag</code> inside your build directory.
You don't have to install KGeoTag (neither system-widely, nor locally) to be able to run it. The executable file will end up at <code>bin/kgeotag</code> inside your build directory.


To work properly however, KGeoTag needs to find some files in standard directories. If you don't install KGeoTag system-wide, you have to make the accessible via your home directory. The easiest approach is to create symbolic links from your sources to your home directory. This way, changes made to those files will be present at once (after restarting KGeoTag). The following files have to be present:
To work properly however, KGeoTag needs to find some files in standard directories. If you don't install KGeoTag system-wide, you have to make the accessible via your home directory. The easiest approach is to create symbolic links from your sources to your home directory. This way, changes made to those files will be present at once (after restarting KGeoTag). The following files have to be present:

Revision as of 10:53, 7 November 2021

This is about KGeoTag, the stand-alone KDE photo geotagging program.

Building KGeoTag from sources

Getting the sources

When working on KGeoTag, you may want to checkout the git sources. KGeoTag's repository can be found on KDE Invent. To clone the sources, simply run

git clone https://invent.kde.org/graphics/kgeotag.git

or, with write access (if you already have a KDE Developer account):

git clone [email protected]:graphics/kgeotag.git

Building the sources

The build process is quite straightforward. It's a "normal" cmake build. So this essentially strips down to (of course inside the source directory):

mkdir build
cd build
cmake ..
make

You may want to use the Ninja build system, in this case you have to use:

mkdir build
cd build
cmake -G Ninja ..
ninja

A common approach is to start as many concurrent build processes as you have CPUs. So for a 4-core CPU, you may want to run

make -j4

or

ninja -j4

respectively.

A good recommendation for development is to create a "Debug" build. This way, you get better (or useable at all) backtraces in case of a crash if you run KGeoTag with a debugger (like gdb), and you get extra warnings whilst compiling. To enable a Debug build, invoke cmake like so:

cmake -DCMAKE_BUILD_TYPE=Debug ..

Running the compiled sources

You don't have to install KGeoTag (neither system-widely, nor locally) to be able to run it. The executable file will end up at bin/kgeotag inside your build directory.

To work properly however, KGeoTag needs to find some files in standard directories. If you don't install KGeoTag system-wide, you have to make the accessible via your home directory. The easiest approach is to create symbolic links from your sources to your home directory. This way, changes made to those files will be present at once (after restarting KGeoTag). The following files have to be present:

kgeotagui.rc             --> ~/.local/share/kxmlgui5/kgeotag/kgeotagui.rc
timezones/timezones.json --> ~/.local/share/kgeotag/timezones.json
timezones/timezones.png  --> ~/.local/share/kgeotag/timezones.png

Installing the compiled sources

This is as simple as a

make install

or

ninja install

respectively. For this case, you have to be root, so either be root or prepend a sudo on distributions that use this concept.

Alternatively, you can define a installation target inside a local prefix to keep all inside your home directory. You have to tell cmake about the changed prefix, e. g. by running

cmake -DCMAKE_INSTALL_PREFIX=~/.local

This is also possible after having already built the sources.

KGeoTag release steps

  • A few weeks before the release, announce a string freeze to the i18n team via [email protected].
  • Don't forget to git pull once again :-)
  • Update ChangeLog.rst with release info and add the new version to CMakeLists.txt (in the project call).
  • Commit the changes, create a tag and push it:
    git commit -a
    git tag -a -m "KGeoTag 1.1.0 released" v1.1.0
    git push
    git push --tags
  • Create a tarball using the releaseme script:
    git pull
    ./tarme.rb --origin trunk --version 1.1.0 kgeotag
  • Upload the tarball and signature file to KDE's FTP server, e. g. via curl:
     curl -T "kgeotag-1.1.0.tar.xz{,.sig}" ftp://upload.kde.org/incoming/
    
  • Use the given link to create a Sysadmin ticket asking to put the files on the mirros.
  • Wait until the files actually hit the mirrors :-D – You can write a release announcement in the meantime.