I am trying to develop a library of shared code for my company.
We are developing on a technology by SICK called AppSpace, which is designed for machine vision. AppSpace is a stand alone eco-system, beneath which there comes a variety of SICK programmable devices (e.g. programmable cameras, LiDAR sensors), and an IDE with which these can be programmed. Programs are written in Lua, using HTML/CSS for the front end.
AppSpace provides a Lua API for these devices.
In my company, a few of us write applications and it is therefore important that we create a library of shared code to avoid redundancy / rewritten code.
However, each firmware version of each device has a corresponding API version. That is to say, that on a given device the API can change between firmware versions, and also that API versions differ across devices. Two devices will have two different sets of API functions available to them. Functions they share in common may also have slightly different implementations.
I am at a loss as to how such a situation can be properly managed.
I suppose the most "manual" route would be for each device to have its own partial copy of the library, and to manually update each device's library to have the same behavior each time a change is made, ensuring that each device conforms to its API. This seems like bad practice as it is very error prone - the libraries would inevitably become out of sync.
Another option might be to have a master library, and to scrape the API documentation for each device. Then build a library manager which parses the Lua code from the library and identifies missing functions for each device. This seems completely impractical and also error prone, probably.
What would be the best way to develop and maintain a library of shared code which can be run on multiple devices, if it is even possible?
I would like to answer this and review some of the topics discussed.
First and foremost; functions that are shared in common between devices will be implemented differently by means of the compiled code on the respective device (i.e. PC, 2d camera, 3d camera, LIDAR, etc) while the functionality maintains the same between them all. This way the code can be readily ported from one device to another. That is the principle of the SICK AppEngine that is running on all SICK AppSpace devices as well as 3rd party hardware with AppEngine installed.
The APIs embedded into the devices are called a CROWN (Common Reusable Objects Wired by Name) component and can be tested against nil to determine if they are exposed APIs. Here's an example of an CROWN called 'IMAGE'. If it exists than you could run this code when it does.
if IMAGE then
--do code
end
SICK also has a AppPool that you can upload your source code to and it will test all the required CROWNs and return a list of all SICK devices that can run properly.