fix: adjust dynamic linking for cmake builds

[lgrossi]

Description

This PR fixes the building for dynamic libraries. After #1438 CMake was always building our internal library canary_lib as a static library, regardless of the building type. Canary_lib for now is just a way of centralizing all our code to use on tests, executable and others, so it has basically everything on it (external deps, multiple internal modules, pre-compiler headers, etc).

Because of that, linking is now very slow, since it always need to link a huge static lib.

We want to allow flexibility, so if you wanna go static you can still use BUILD_STATIC_LIBRARY bo build everything statically. However, for tests and dynamic local development, it's quite handy that we provide a dynamic library as well.

Change

When adding the library to CMake, we now define its state based on `BUILD_STATIC_LIBRARY``.

Context

Dynamic Libraries

• Think of them as external buddies. Your app calls on them when it runs, so they must be around.
• They're separate files (.dll, .so, .dylib).
• Multiple apps can share one copy, saving space.
• But if the app expects a specific version and doesn't find it, things can break.

Static Libraries

• They're like your app's built-in muscle. Everything's packed into the app itself.
• No external files to worry about.
• Makes your app bigger since it's carrying the library around.
• Super reliable, since there's no hunting for external files during runtime.

Choosing between them?

If you want a single, beefy file with no external dependencies, go static.
If you're cool with external files and like sharing code between apps, go dynamic.

Bonus

We're breaking down target_source into smaller chunks to improve visibility.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information