The Storyboard Designer install ships with several sample applications which make use of additional community sourced Lua modules to extend the capabilities of the standard runtime plug-ins. Two examples are the comms modules for the SocketJSON sample and the database functionality behind the LuaSqliteDatabase sample.
If we take a closer look at the LuaSqliteDatabase sample you will find an implementation that uses sqlite3 libraries and a simple database populated with some users and data values for controls:
The Lua modules underpinning the database functionality are required to be first loaded by the Lua engine.
Remember to check that these additional files and resources have been included in the deployment configuration. The Storyboard Application Export Configurations dialog and Export Resources tab allows you to add resources to your target filesystem:
The code that loads the library dependencies is as follows and can be seen in callbacks.lua:
-- This is where we do all of the Database interaction and initialization.
-- we connect, query, and update our target database table via the sqlite3 plugin
local myenv = gre.env({ "target_os", "target_cpu" })
if(myenv.target_os=="win32")then
package.cpath = gre.SCRIPT_ROOT .. "\\" .. myenv.target_os .. "-" .. myenv.target_cpu .."\\luasql_sqlite3.dll;" .. package.cpath
else
package.cpath = gre.SCRIPT_ROOT .. "/" .. myenv.target_os .. "-" .. myenv.target_cpu .."/luasql_sqlite3.so;" .. package.cpath
end
luasql = require("luasql_sqlite3")
local database = "usersettings.sqlite"
local env = assert(luasql.sqlite3())
local db = assert(env:connect(gre.SCRIPT_ROOT .. "/"..database, "Failed to connect to database"))
local users = {}
local currentUser = 1
:
You can see that we have used some OS specific environment values to automatically create the load path (package.cpath) needed for the luasql_sqlite3 libraries on x86 Linux, MacOS and Windows as part of this project so that you can run these samples in the desktop environment and simulator.
The Storyboard install only includes the appropriate DLLs or shared libraries for these targets but we do build them for most of our embedded targets.
In the example screenshot above I have added the linux-armle folder and populated it with the cross-compiled luasql_sqlite3.so shared library matching the target toolchain and processor architecture.
This binary library is from our Lua libraries package.
Note
We do not include the ‘Lua libraries’ package for every target runtime for installer size reasons however, they are generally available at no charge. You can request these via email to your account manager at sales@cranksoftware.com or through our support channels at support@cranksoftware.com .
It is recommended that you prepare and build your own Lua libraries packages where possible so that you can take advantage of updates and bug fixes as part of your product development processes and procedures.
This is generally straightforward as it aligns with your other build tasks. There are a few guidance notes which should make this trouble free:
-
LuaRocks is awesome however this builds libraries for your desktop development environment by default which is great for simulation and testing but unfortunately probably NOT compatible with your target board
-
Instead, pull the sources and build your own libraries:
-
Cross-compile for the target architecture you need using the right toolchain and make
-
Always link against the Storyboard Lua library (sblua) to ensure that the API is compatible
-
Likewise, ensure that you use the same version of the Lua libraries as the Storyboard core (Lua 5.1)
-