|
|
|
<
< |
|
>
> |
| Story summary | Get all the plug-ins building, loading, and working in the same manner |
|---|
|
|
|
|
<
< |
|
>
> |
|
|
| FEA | |
|---|
| Acceptance Criteria | |
|---|
| Passed acceptance test | No |
|---|
Full story
|
|
>
> |
Our support for C++ plug-ins is relatively new, and we have learned things since we started. That knowledge needs to be applied to all the modules that handle plug-ins.
|
|
Implementation notes
|
|
>
> |
The modules that have plug-ins are:
- Gadgeteer
- Device drivers
- ClusterJuggler plug-ins
- JCCL
- Remote run-time reconfiguration
- Sonix
All need to support the following:
- Proper compilation
- Plug-ins are built after the library upon which they depend
- Plug-ins can be built separately from their dependent library
- This makes it easier and faster to develop and test plug-ins
- Plug-ins must be built to address different ABIs
- Debug versus optimized (critical for Windows)
- N32/64
|
|
Tasks in this story
|
|
<
< |
|
>
> |
| Task | 0 | 0 | 0 | Low | | | Build ClusterJuggler plug-ins separately from Gadgeteer |
| Task | | | | Low | | | Handle ClusterJuggler plug-ins abstractly in configuration and code |
| Task | | | | Low | | | Convert Sonix plug-ins to use vpr::Library |
| Task | | | | Low | | | Build Sonix plug-ins separately from Sonix |
| Task | | | | Low | | | Handle Sonix plug-ins abstractly in code |
|
|
Task details:
|
|
>
> |
Handling plug-ins "abstractly in code" means that the code operates on a platform- and ABI-independent level in terms of the plug-in name. The Gadgeteer device driver handling in gadget::InputManager and the remote run-time reconfiguration plug-in handling in jccl::ConfigManager demonstrate how to do this.
Build system adjustments should be based on the way that the Gadgeteer device drivers are compiled.
|