||7 months ago|
|.gitlab/issue_templates||2 years ago|
|cmake||7 months ago|
|db||1 year ago|
|server||7 months ago|
|test||1 year ago|
|vendor/headers||11 months ago|
|.clang-tidy||1 year ago|
|.gitattributes||1 year ago|
|.gitignore||1 year ago|
|.gitlab-ci.yml||2 years ago|
|.reek.yml||1 year ago|
|.rubocop.yml||1 year ago|
|CHANGELOG.md||11 months ago|
|CMakeLists.txt||10 months ago|
|CONTRIBUTING.md||1 year ago|
|Doxyfile||1 year ago|
|LICENSE.md||2 years ago|
|README.md||1 year ago|
|TODO||2 years ago|
|config.hpp.in||1 year ago|
Calypso provides a secure collaboration server using the ZMQ library and curve crypto sessions.
Basic documentation, including an architecture overview, will be added as markdown files. User operation, server admin, and configuration should be similarly added here. An installation guide for various GNU/Linux distributions and BSD systems may also be added. Developer documentation can be generated from source file headers using Doxygen.
A typical "install" target is created to support local installation. This should include an example config file. On openrc systems this may install an init script. A logrotate config can also be added. All running directories that may be required are either made by "install" or created when the service executes. Execution in daemon mode is done by the init script.
When cmake is used to produce a Debug build this instance can be executed directly; no further install is required. The debug build uses the config file found in the test/ directory, and a test/custom.conf file can be added with configuration overrides for local developer testing. The preferred cmake build type for live installation and running of debug builds is RelWithDebugInfo.
A more complete overview of participation will be provided in CONTRIBUTING.md. This project uses cmake, and c++17 for core server development. I use the ctest framework for unit testing and gcovr for coverage reports. Calypso can be built with gcc or clang and can be tested on just about any posix platform, including bsd systems.
In addition to producing testable debug builds the project can also be built for running unit tests. This is enabled by default for debug builds. To produce coverage reports you can cmake a debug build with -DCOVERAGE_TYPE=gcov set. You can then use the make the "coverage" target and produce coverage reports with gcovr or lcov. The "lint" target will validate code using cppcheck.
The easiest way to begin participation is installing doxygen and graphviz, and then building the ``docgen'' target. This produces browsable code documentation and provides quick access to project resources, such as the issue tracker, merge requests, ci pipelines, milestones, the project development wiki, etc.
Support is offered thru our issue tracker using email@example.com. I also have firstname.lastname@example.org. Build support and packaging, especially for openSUSE and Debian GNU/Linux, will be found on the openSUSE build service (https://build.opensuse.org/project/show/home:dyfet). I have my own build infrastructure for Alpine using ProduceIt, and I publish binary packages thru https://public.tychosoft.com/alpine. In the future maybe other means of support will become possible.