TANGO kernel c++ implementation
Switch branches/tags
Clone or download
Latest commit 07eea09 Dec 13, 2018



TangoControls CLion

Build Status Build status




Quality gate

Maintainability Reliability Security

Bugs Code smells Vulnerabilities Tech debt

Lines of code Lines of code

TANGO distributed control system - shared library

TANGO is an object-oriented distributed control system. In TANGO all objects are representations of devices, which can be on the same computer or distributed over a network. Communication between devices can be synchronous, asynchronous or event driven.

The object model in TANGO supports methods, attributes and properties. TANGO provides an API which hides all the details of network access and provides object browsing, discovery, and security features.

For more information please visit www.tango-controls.org.

cppTango - tango-9-lts branch

This repository is the result of svn2git migration of Tango source code previously hosted on tango-cs Sourceforge project. It is combined from api/cppapi, api/log4tango, api/cpp_test_suite anf api/cpp_test_ds

cppTango tango-9-lts branch is the branch dedicated to Tango 9 Long Term Support version.


On readthedocs: tango-controls.readthedocs.io

API reference: tango-controls.github.io/cppTango-docs

Old Manuals: tango-controls.org/documentation/kernel

How to build and install using cmake

mkdir build; cd build; cmake .. [-DCMAKE_INSTALL_PREFIX=<desired installation path>] [-DIDL_BASE=<tango-idl installation folder>] [-DOMNI_BASE=<omniORB4 home folder>] [-DCPPZMQ_BASE=<cppzmq home folder][-DZMQ_BASE=<zmq home folder>] [-DCMAKE_BUILD_TYPE=Release|Debug] [-DCMAKE_VERBOSE_MAKEFILE=true]; make; make install

More information is in INSTALL file

Using pkg-config

Once installed cppTango provides pkg-config file tango.pc

One can use it to resolve libtango dependencies in his project, for instance using cmake:

pkg_search_module(TANGO_PKG REQUIRED tango)



#note TANGO_PKG_XXX usage
add_executable(${PROJECT_NAME} ${SOURCES} ${HEADERS})
target_compile_options(${PROJECT_NAME} PUBLIC -std=c++11)
target_compile_definitions(${PROJECT_NAME} PUBLIC ${TANGO_PKG_CFLAGS_OTHER})
target_link_libraries(${PROJECT_NAME} PUBLIC ${TANGO_PKG_LIBRARIES})

tango.pc provides default installation directory for all Tango devices linked against this libtango:

pkg-config --variable=tangodsdir tango

How to test

1. First build everything

mkdir build; cd build; cmake ..; make

2. Start TANGO environment

make start-tango

Typical output: Note env.TANGO_HOST value: this is normal TANGO_HOST that can be used, for instance, in Jive

Setup test environment
 Create tango_host file
 Wait till tango-cs is online

3. Run tests

make run-tests

Before running tests CTest runs conf_devtest (located in cpp_test_suite/new_tests) and starts DevTest and FwdTest device servers (located in cpp_test_ds)

4. Shutdown TANGO environment

make stop-tango

For information on how to run individual tests see INSTALL file

How to contribute

See corresponding wiki page

Usage workflow (draft)

  1. In its most basic form, we adopt the githubflow : the default branch is master, which is always in a deployable state (i.e. must never be broken); work on new features is done using temporary feature branches (which may live in the same repo or in a fork)
  2. Reporting issues: use github issues
  3. Code contributions: use Pull requests. Pull requests can be associated with issues. Trivial fixes can even be done from the web (a temporary branch is created automatically to use the Pull request infrastructure)
  4. Code review: most projects (all except single-developer ones) should only allow commits to the master branch after peer review. This can be enforced by the convention that all commits to master must be done via a Pull request and the pull request approved by a person different from the author of the commit.
  5. Releases (named versions):
  • Simple projects may be ok with just tagging certain (ideally, all) commits done to the master branch with a version number. With this system, only one release is actively maintained simultaneously.

  • More complex projects may require to simultaneously maintain more than one release (e.g. Tango may choose to support bugfixes in Tango9 even after Tango10 is released). In this case, releases may be done on release branches starting from master (see APPENDIX I for an example)

  1. Semantic versioning is recommended.
  2. Public automatic testing/continuous integration (e.g., via Travis) is recommended
  3. The main development should be done on the tango-controls hosted project (as opposed to using a private organization project and just pushing to the tango-controls repo from time to time). This allows for public visibility of the latest development and issues and encourages sharing and reuse. If a given organization needs special tweaks or has particular release/testing cycles, the recommendation is that the organization forks from the "canonical" repo


Tango Controls web page