Project Guidelines

This article outlines best practices for maximizing the capabilities of the SPARK SDK as well as the advantages of adhering to its architecture.

Best Practices

Inclusion as a library: It is encouraged that the SDK be included into projects as a library, meaning that it can be updated via a drop in replacement.

Source File Integrity: Direct modification of SDK source files is discouraged to ensure that updates do not overwrite customizations or introduce compatibility issues. It is suggested to extend the functionality through project-specific code.

Build System Independence: Create an independent CMakeLists.txt file within the project’s root directory, rather than using the SDK’s top-level CMakeLists.txt. Include and link the necessary SDK components by specifying the paths to their respective directories within the SDK package.

Backend Flexibility: The SDK is designed for the injection of custom backend implementations. This ensures the integration of hardware-specific functionalities by adhering to the facades defined in each SDK code component.

Note

A code component—such as a module, library, or application—is a distinct section of source code designed for a specific functionality.

Advantages

Ease of Maintenance: Separating the project from the SDK simplifies updates and ensures that ongoing work is not adversely affected.

Reduced Errors: Maintaining this separation significantly reduces the risk of introducing errors, contributing to a more stable and predictable development environment.

Scalability: This architectural approach allows more efficient project scaling. Project-specific modifications remain isolated, leaving the SDK package unaltered, which facilitates scaling and customization.