5 - [Documentation](#documentation)
6 - [Compilation](#compilation)
7 - [Installation](#installation)
8 - [Running unit tests](#running-unit-tests)
9 - [Using SDL in application pod](#using-sdl-in-application-pod)
13 Documentation is generated with `doxygen` tool. Dependency to `doxygen`
14 tool is optional. If not installed, then `doxygen-doc` target will not
15 be created to Makefile.
17 By default `make doxygen-doc` creates HTML, PDF and PS documents (if
18 the needed tools are available). The documents are created to:
20 1. doxygen-doc/html/index.html
21 2. doxygen-doc/shareddatalayer.pdf
22 3. doxygen-doc/shareddatalayer.ps
24 Creation of different document formats can be controlled with various
25 `--enable-doxygen-*` and `--disable-doxygen-*` configuration
26 options. For example if only HTML document is needed, then run:
28 ./configure --disable-doxygen-pdf --disable-doxygen-ps
33 These instructions assume that the project has been cloned into
34 directory named `shareddatalayer`.
38 Build-time dependencies:
44 Commands to install dependent packages in Fedora:
46 sudo dnf install boost-devel
47 sudo dnf install hiredis-devel
48 sudo dnf install doxygen
50 Commands to install dependent packages in Debian/Ubuntu:
52 sudo apt install libboost-all-dev
53 sudo apt install libhiredis-dev
54 sudo apt install doxygen
56 ### Compilation in the source directory
63 ### Compilation outside the source directory
70 ../shareddatalayer/configure
75 By default the shared library is installed to `/usr/local/lib` and
76 headers into to `/usr/local/include`. If this is not desired, then
77 provide different path when running `configure`, for example:
79 ./configure --prefix=$HOME/usr/local
81 In above example SDL pkg-config .pc file is installed to `$HOME/usr/local/lib/pkgconfig`
82 directory. This directory should be included to `PKG_CONFIG_PATH` while building
83 the application which is using the SDL API library.
85 Note that `configure` command allows plethora of additional options.
90 After configuration has been done, run:
94 In some cases dynamic linker cache needs to be manually refreshed after SDL API
95 has been re-installed:
101 When Redis is used, SDL requires that the following Redis extension commands
102 have been installed to runtime environment:
111 Redis v4.0 or greater is required. Older versions do not support extension
114 Implementation for these commands is produced by RIC DBaaS:
115 https://gerrit.o-ran-sc.org/r/admin/repos/ric-plt/dbaas
117 In official RIC deployments these commands are installed by `dbaas` service to
120 In development environment you may want install commands manually to pod/container
121 which is running Redis.
123 Installation to default system directory:
130 Following line should be added to `redis.conf` file:
132 loadmodule <path>/libredismodule.so
134 `<path>` should be replaced to match library installation directory path.
135 `redis-server` must be restarted after configuration file update.
137 Notice that `redis-server` takes path to configuration file as an argument.
138 If not given it will start with default parameter values and above made
139 `loadmodule` option is not effective. Refer to `redis-server --help`.
141 SDL API will check in connection setup phase that all required commands are
142 available, if not then execution is aborted and error log is written to identify
143 that which commands are missing.
145 ## Running unit tests
147 Unit tests are compiled and executed by simply running:
151 By default all unit tests are executed. If `valgrind` is installed,
152 then by default unit test execution is analyzed with `valgrind`.
153 Running specific test cases can be achieved by using `GTEST_FILTER`
154 environment variable. For example:
156 make test GTEST_FILTER=ConnectionTest*
158 If `valgrind` is not desired (even if installed), then it can be
159 disabled with `USE_VALGRIND` environment variable:
161 make test USE_VALGRIND=false
163 Additional `valgrind` arguments can be specified with `VALGRIND_EXTRA_ARGS`
164 environment variable. For example:
166 make test VALGRIND_EXTRA_ARGS='--track-fds=yes --log-file=mylog.txt'
168 It is also possible to use the `testrunner` binary directly (after it
169 has been compiled). The `testrunner` binary supports all the command
170 line options gtest supports, for example:
175 ## Running unit tests with gcov
177 Enable unit test gcov code coverage analysis by configuring gcov reporting
180 configure --with-gcov-report-dir=DIR
182 Directory can be an absolute path or a relative path to an SDL source root.
183 Unit test build creates directory if it does not exist.
185 Build and run unit tests with code coverage analysis:
189 After successful unit test run code coverage (.gcov) result files are in
190 a directory, what was defined by '--with-gcov-report-dir' configure option.
192 In addition, graphical gcov front-ends such as lcov can be used for coverage
195 lcov --directory tst/ --directory src --capture --output-file coverage.info
196 genhtml coverage.info --output-directory out
198 Open the out/index.html using any web browser.
200 ## Using SDL in application pod
202 SDL is not yet available in O-RAN-SC PackageCloud.io repository.
204 Plan is to add it, but in the meantime SDL API needs to be complied and installed
205 in SDL client Dockerfiles (refer instructions above). You may need to execute
206 `RUN ldconfig` command to Dockerfile after SDL API installation.
208 RIC DBaaS service must be running before starting application pod which is using SDL
209 API. DBaaS defines environment variables which are used to contact DBaaS service
210 (offering backend for SDL). Those environment variables are exposed inside application
211 container only if DBaaS service is running when application container is started.
213 You may test SDL connectivity to its backend with `sdltool test-connectivity`
214 command inside your application container.