Skip to content

Electrostat-Lab/Electrostatic-Library

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

11 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Electrostatic-Library

A library template utilizing the Electrostatic-Sandbox SDK, acting as an extension pack.

This is a template that builds a cross-platform native library for Linux variants, Android variants, and AVR MCU variants linking them against the Electrostatic-Sandbox SDK libraries. The library is built into static archives, and dynamic libraries. The template is also provided by examples module in which a single source file with a main function could be compiled and run on its respective system.

image

System Requirements

  1. A GNU/Linux System or a WSL System.
  2. A minimum of 1GB RAM, and 4GB Disk Space.
  3. If planned Microcontroller development; ATMega32 and/or ATMega328p are the currently supported ones.
  4. If planned Android development; all Android variants are supported.

Setup the Electrostatic Environment

This will install missing dependencies (CLI tools and toolchains) in /opt/electrostatic-sandbox that shall be utilized by the SDK build front-end and CMake to build the applications.

chmod +rwx ./helper-scripts/setup-environment/setup-sandbox.sh && \
           ./helper-scripts/setup-environment/setup-sandbox.sh

Build the application binary (.elf)

This will build the application binary to all supported platforms; usually if a new build routine is to be built, it has to go here.

chmod +x ./helper-scripts/project-impl/compile-all.sh && \
         ./helper-scripts/project-impl/compile-all.sh 

Introducing other building routines using Bash

Introducing other building routines is far easy. However, it's mostly dependent on whether the original SDK is supporting those platforms. If not yet, you will have to build a pre-compilation header that excludes the SDK for those unsupported systems or else you will get linking errors.

Usually the build routines will look like that in general:

#!/bin/bash
source "./helper-scripts/project-impl/variables.sh"
source_module="${lib_src}"
./helper-scripts/project-impl/compile-electrostatic.sh \
"${COMMISSION_LIB}" "${GCC_BIN_x86}" "${GPP_BIN_x86}" "ON" "ON" "OFF" "-O3 -fPIC" \
"${TARGET_x86_64}" "${TOOLCHAIN_INCLUDES_x86};${headers}" "${source_module}" \
"${libs}/linux/x86-64" "m;pthread;dl" "${source_dir}" \
"linux" "${x86_64}" "${POST_COMPILE_TRUE}" "false"
./helper-scripts/project-impl/compile-electrostatic.sh \
"${COMMISSION_LIB}" "${GCC_BIN_x86}" "${GPP_BIN_x86}" "ON" "ON" "OFF" "-O3 -fPIC" \
"${TARGET_x86}" "${TOOLCHAIN_INCLUDES_x86};${headers}" "${source_module}" \
"${libs}/linux/x86" "m;pthread;dl" "${source_dir}" \
"linux" "${x86}" "${POST_COMPILE_TRUE}" "false"

They are dependent on that abstraction:

#!/bin/bash
function compile() {
local COMMISSION_OUTPUT=${1}
local GCC_BIN=${2}
local GPP_BIN=${3}
local BUILD_STATIC=${4}
local BUILD_SHARED=${5}
local BUILD_EXE=${6}
local INPUT_COMPILER_OPTIONS=${7}
local TARGET=${8}
local HEADERS=${9}
local SOURCES_DIR=${10}
local PROJECT_SOURCES=${11}
local DEPENDENCIES=${12}
local BUILD_DIR=${13}
local CMAKE_DIR=${14}
local TEMP=$(pwd)
cd "${CMAKE_DIR}" || exit $?
cmake-3.19 "-DCOMMISSION_OUTPUT=${COMMISSION_OUTPUT}" \
"-DGCC_BIN=${GCC_BIN}" \
"-DGPP_BIN=${GPP_BIN}" \
"-DBUILD_STATIC=${BUILD_STATIC}" \
"-DBUILD_SHARED=${BUILD_SHARED}" \
"-DBUILD_EXE=${BUILD_EXE}" \
"-DINPUT_COMPILER_OPTIONS=${INPUT_COMPILER_OPTIONS}" \
"-DTARGET=${TARGET}" \
"-DHEADERS=${HEADERS}" \
"-DSOURCES_DIR=${SOURCES_DIR}" \
"-DPROJECT_SOURCES=${PROJECT_SOURCES}" \
"-DDEPENDENCIES=${DEPENDENCIES}" \
"-DBUILD_DIR=${BUILD_DIR}" \
-S . -B "$(pwd)/${SOURCES_DIR}/cmake-build/${BUILD_DIR}"
cmake-3.19 --build "$(pwd)/${SOURCES_DIR}/cmake-build/${BUILD_DIR}" || exit $?
cd "${TEMP}" || exit $?
}

Changing the project output name

This could be attained by changing the variable COMMISSION_LIB and COMMISSION_LIB_AR in the ./helper-scripts/project-impl/variables.sh:

COMMISSION_LIB="electroextension"
COMMISSION_LIB_AR="electroextension-a"

Adding new dependencies

Add your dependencies in the libs directory with the system directory of choice if required (in case of platform-dependent binaries); the build script finds all libraries listed under this directory through this code snippet:

# precompile scripts
sources=$(find ${CODEBASE_MODULES[*]} -name *.c -o -name *.cpp -o -name *.cxx | tr '\n' ';')
if [ "${DEPENDENCIES_MODULES[*]}" != "${NULL}" ]; then
if [ "${DYNAMIC_LINKING}" == "true" ]; then
echo -e "--------- Deferring Linking to runtime ---------"
dependencies=$(find ${DEPENDENCIES_MODULES[*]} -name *.so | tr '\n' ';')
else
echo -e "--------- Performing Static Linking ---------"
dependencies=$(find ${DEPENDENCIES_MODULES[*]} -name *.a -o -name *.ar | tr '\n' ';')
fi
fi

Adding new examples to test the introduced APIs

  • Adding new examples could be achieved by creating new source code (single source files) under the examples module, and using the following command to compile and run the example:
$ ./helper-scripts/project-impl/compile-examples.sh "-m64" "main.cpp" "executable-example" "linux" "x86-64" "x86-64/exe"
$ ./cmake-build/linux/x86-64/exe/executable-example.elf

Note

This command links the specified source example against the Electrostatic-Sandbox SDK libraries and the Electroextension library (your native library).

  • Adding new examples for microcontroller programming is much the same, but will require uploading as a post-compilation script.

Excluding parts of the source code (dissociating the source code into modules)

This could be attained through the build routines of the supported systems by decomposing the source directory into sub-directories and pass them as source modules to the compilation front-end (Ccoffee); the following shows the use of all the source code as a single module:

source_module="${lib_src}"
./helper-scripts/project-impl/compile-electrostatic.sh \
"${COMMISSION_LIB}" "${CLANG_BIN}" "${CLANGPP_BIN}" "ON" "ON" "OFF" "-O3 -fPIC" \
"--target=${ARM_64}" \
"${NDK_TOOLCHAIN_INCLUDES};${headers}" "${source_module}" \
"${libs}/android/${ARM_64}" "m;c;dl" "${source_dir}" \
"android" "${ARM_64}" "${POST_COMPILE_TRUE}" "false"

Build front-end automata, CMake, and Toolchains

Essentially, the build architecture of the Electrostatic-Sandbox SDK is based on the idea of creating a front-end scripted API that creates a building automata, which entails taking an input and passing into a chain of states, and eventually ending with a terminal state; thus the recognition of the machine to the building holds if the terminal state is being reached by the program counter. The initial input to the automata is mainly a building routine instruction and the outputs are proceeded and could be found at the filesystems cmake-build and build, where the terminal output is produced.

The build of the Electrostatic-applications is much simpler than the SDK; it's literally a subset of it.

For more; refer to the build architecture of the Electrostatic-Sandbox SDK.

About

A native library extension to the Electrostatic-Sandbox SDK; on which native binding APIs could attach.

Topics

Resources

License

Contributing

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published