Skip to content
Snippets Groups Projects
Commit 77b04a4e authored by Sebastian Oberschwendtner's avatar Sebastian Oberschwendtner
Browse files

Updates the developer libraries instructions.

parent 375da8ef
Branches
No related tags found
3 merge requests!76Draft: Updated Python code example,!73Initial open source version,!1Doxygen setup for contionuous documentation
Pipeline #1071341 passed
......@@ -5,35 +5,52 @@ authors:
- Sebastian Oberschwendtner
date: 2023-09-12
---
= A word about including the libraries =
## A word about including the libraries
Oh yes, the **UNICADO** [libraries](../modules/libraries.md). 🙂
When you start developing and building the **UNICADO** modules you will quickly discover the importance of the libraries.
There are many ways how you can include libraries in C++ projects and all have their advantages and disadvantages.
In the **UNICADO** project, the most important decisions to make are:
Oh yes, the //UNICADO// [[unicado_description/#libraries | libraries]]. 🙂 When you start developing and building the //UNICADO// modules you will quickly discover the importance of the libraries. There are many ways how you can include libraries in C++ projects and all have their advantages and disadvantages. In the //UNICADO// project, the most important decisions to make are:
- Whether to include the libraries as **static** (`*.a`) or **dynamic** (`*.dll` or `*.so`) libraries.
- Whether to include the libraries as **CMake** //targets// and always recompile the libraries when building the modules or to import the libraries as a **CMake** //package// somewhere from the hard drive. ( {icon arrow-right} Look in [[ build_instructions/include_library_package | Include Library Package ]] to find out what this actually means.)
- Whether to include the libraries as **CMake** **targets** and always recompile the libraries when building the modules or to import the libraries as a **CMake** **package** somewhere from the hard drive. ( :fontawesome-solid-arrow-right: Look in [ Include Library Package ](#) to find out what this actually means.)
> Note that each decision is completely independent from the other decision.
Each of those decisions has a corresponding option when configuring **CMake**. So you can decide for your situation what suits your workflow the best. The default configuration when [[#configure-cmake | configuring]] and [[ #build-with-cmake | building]] //UNICADO// is:
- `BUILD_SHARED_LIBS=OFF` {icon arrow-right} Build **static** libraries.
- `FIND_LIBRARIES_AS_PACKAGE=OFF` {icon arrow-right} Include //targets// from the submodule and recompile libraries each time there are changes.
Each of those decisions has a corresponding option when configuring **CMake**.
So you can decide for your situation what suits your workflow the best.
The default configuration when [Building with CMake](build-cpp.md) is:
- `BUILD_SHARED_LIBS=OFF` :fontawesome-solid-arrow-right: Build **static** libraries.
- `FIND_LIBRARIES_AS_PACKAGE=OFF` :fontawesome-solid-arrow-right: Include **targets** from the submodule and recompile libraries each time there are changes.
NOTE: The default configuration is usually best suited for most situations.
!!! note
The default configuration is usually best suited for most situations.
=== Changing to dynamic libraries ===
## Changing to dynamic libraries
When you want to decrease the binary size of the executables or want to test changes in the libraries without having to recompile the executables, you can build the libraries as **dynamic** libraries by configuring **CMake** with:
lang=sh
cmake -B build -S . -G "your-generator" -DBUILD_SHARED_LIBS=ON
This will build all libraries as **dynamic** libraries and link the executables against those libraries. It does not matter where you set this option. When you build the libraries on their own, the option does the same thing as when you build the complete project where the libraries are included as a submodule.
```sh
cmake -B build -S . -G "your-generator" -DBUILD_SHARED_LIBS=ON
```
NOTE: Do not forget to add the location of the **dynamic** libraries to your **PATH** afterwards. 😉
This will build all libraries as **dynamic** libraries and link the executables against those libraries.
It does not matter where you set this option.
When you build the libraries on their own, the option does the same thing as when you build the complete project where the libraries are included as a submodule.
=== Changing to the library package ===
!!! warning
Do not forget to add the location of the **dynamic** libraries to your **PATH** afterwards. 😉
## Changing to the library package
When you want to save some compilation time or do not want to copy the libraries everywhere, you can include them as a package by:
lang=sh
cmake -B build -S . -G "your-generator" -DFIND_LIBRARIES_AS_PACKAGE=ON -DCMAKE_PREFIX_PATH=path-to-libs
IMPORTANT: When including the libraries as a package you __HAVE__ to set `CMAKE_PREFIX_PATH` as described in [[ build_instructions/include_library_package | Include Library Package ]]. You also have to make sure that the libraries this path is pointing to are compiled and exist!
```sh
cmake -B build -S . -G "your-generator" -DFIND_LIBRARIES_AS_PACKAGE=ON -DCMAKE_PREFIX_PATH=path-to-libs
```
!!! important
When including the libraries as a package you ^^**HAVE**^^ to set `CMAKE_PREFIX_PATH` as described in [ Include Library Package ](#). You also have to make sure that the libraries this path is pointing to are compiled and exist!
With this mechanism you can have mutliple projects using the same libraries without having to copy and recompile them all the time. The added downside is that **CMake** can no longer handle the automatic compilation and you have to manually make sure that the libraries are ready to be used.
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment