Understanding the framework library layout

The framework has multiple packaging modes. This page serves as an introduction to them and their subsequent library and executable layouts.

Static vs. Shared mode

When compiling in static mode, all framework, application and wrapper executable code is packaged into a single executable. In shared mode, depending on the platform, the framework, application and wrapper executable are separate atoms that are loaded at runtime. More information below.

Shared mode Windows

On Windows, shared mode produces 2 binaries:

1. The framework-application library
2. The wrapper executable

The framework-application library combines the code of the framework and application into a single DLL, which is then loaded by the wrapper executable or by plugins.

This approach is different from Unix, where there are 3 binaries. This is mainly caused by restrictions placed on us by MSVC and on us trying to discourage shipping the framework system-wide.

---

Because the library is not supposed to be shipped globally, disabling modules at compile time is a fine thing to do.

Shared mode on Unix

On Unix-based systems, shared mode produces 3 binaries:

1. Framework library
2. Application library
3. Wrapper executable

In most cases, the framework library, produced by building the application locally, is used only in development, as the same application deployed as a production package may use the system-wide framework library.

The application library is a shared library that contains all source code under Source/.

---

This layout is preferable on Unix systems, as the framework library can be shipped globally, while allowing plugins to access application code through the application library.