Maintainer's Guide

This page is for libpointing-developers

Project structure

The project consists of:

• Libpointing main classes
• Applications which use libpointing
• Unit tests
• Echomouse-based transfer functions
• Building and Packaging scripts

Build system

To build libpointing qmake is used. Additionally, on Windows you can build with Visual Studio. To run tests: qmake && make check -s.

Continuous Integration

Currently, the repository is configured to compile the project on all 3 platforms and perform unit-tests on each commit. If a build or tests fail, status images will show that the build is broken. To access the repository from CI servers special personal access tokens were created. For Travis, $GITHUB_API_KEY is used to define the hidden token. For Appveyor the generated token was encoded securely and put directly into appveyor.yml.

Windows

appveyor.yml is used to configure CI on Windows. Currently, libpointing is built using Qt (VS2013, VS2015 and MinGW compilers), Visual Studio 2013 and Visual studio 2015.

Mac OS and Linux

.travis.yml is used to configure CI on Mac OS and Linux.

Continuous Deployment

To deploy libpointing:

1. Change the version in pointing/pointing.h file.
2. Commit and push.
3. Create a new tag with git tag -a v{major.minor.release} -m "Short release description" (remove {}).
4. Push this tag with git push --tag.

Travis and Appveyor are configured to deploy automatically when a tag is provided. It may take some time to build and deploy all the files to Github Releases.

Windows

Appveyor CI will output .lib-files onto Github Releases.

Linux

Travis builds and tests the project using qmake && make check -s. Then this script is used to build a deb-package (without qmake). Packages.gz and .deb files are pushed onto gh-pages branch using update_site script.

Mac OS

This script is used to build libpointing without qmake, to create a tarball and output Release files.

Homebrew

Normally, Travis CI should build, update version and commit changes to INRIA/libpointing-homebrew. All you need to do is to create a pull request and describe the changes. Here is the detailed description of what is done by Travis:

• New version of libpointing is built and a corresponding tarball is created.
• INRIA/libpointing-homebrew is cloned and a new branch named libpointing is created each time and changes (version number and checksum) are committed and pushed to origin/libpointing.

Macports

Modify libpointing Portfile in /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/libpointing and then create a patch-file as described here. Normally, the version number and checksums fields should be modified. Checksums of the appropriate .tar.gz (Github Releases) should be written, using the following commands, for example:

openssl dgst -rmd160 libpointing-mac-1.0.4.tar.gz
openssl dgst -sha256 libpointing-mac-1.0.4.tar.gz

Make sure libpointing-mac-XXXX.tar.gz compiles and create a patch-Makefile.diff to fix the makefile if required. Manually test your patch before creating a ticket and submitting the new version.

gh-pages

This branch can be used to serve a static web-site. All the data map to the address inria.github.io/libpointing.

Documentation

Please use this wiki for documentation. In addition, on each release the Doxygen documentation will be updated by Travis CI. GH-pages branch is used to deploy the web-site.

NPM

libpointing

In order to release a new version of the npm package libpointing one needs to:

• Login with libpointing user with npm login.
• Modify package.json.
• Run npm publish in bindings/Node/libpointing folder.

This will publish the latest version.

pointingserver

Publishing is done in the same way as for libpointing npm package.