- 1 GSOC 2014: Windows Port
- 1.1 Work items
- 1.1.1 Identify POSIX-specific functionality
- 1.1.2 Minimal GCC/MinGW build
- 1.1.3 Documentation
- 1.1.4 Unit tests
- 1.1.5 Network-based plugins
- 1.1.6 Example programs
- 1.1.7 Installer
- 1.1.8 MSVC support
- 1.1.9 olad service
- 1.1.10 Python interface
- 1.1.11 Device plugins
- 1.1.12 Testing and CI
- 1.1.13 I18N issues
- 1.2 Status
- 1.1 Work items
GSOC 2014: Windows Port
For Google's Summer Of Code 2014, the Windows port has been accepted as a project. This wiki page gives an overview of the different work items that are part of this project, and the overall progress. All development happens on github at https://github.com/lukase/ola, and progress is continually merged upstream into the main OLA repository.
Identify POSIX-specific functionality
Many parts of OLA use POSIX-specific functionality that's not available on Windows, such as daemon handling, user profile handling, and a general purpose select() call. For each of these functions, equivalent functions on Windows have to be researched, or alternatives have to be designed. Currently, the biggest problem lies with the SelectServer, for which there is no equivalent solution with equal scope on Windows.
Minimal GCC/MinGW build
In order to reduce the complexity of the port, the first goal is to get a minimal build of OLA up and running (i.e. disable as much functionality as possible).
Documentation on how to build OLA on Windows can be found on the wiki and in the repository itself (README.mingw32). It will continually be updated to reflect the current status of the port.
After the minimal configuration of OLA can be built, the next step will be to re-enable the unit tests and make sure all of them pass.
Since these plugins don't rely on special hardware, network protocols are the first plugins to be re-enabled.
Since the example programs use libola, they serve as a first test of the port's usability for client programs.
In order to simplify libola usage for Windows developers, an installer will be created that contains pre-built binaries for MinGW. Once MSVC support is available, it will be added to the installer as well.
Microsoft Visual C++ is the dominant compiler on Windows platforms. Once the basic MinGW port is completed, support and project files for MSVC will be added.
The Windows equivalent to daemons are services. It should therefore be possible to start olad as a Windows service.
For this item, the Python binding will be enabled on Windows as well.
Depending on hardware availability, plugins for various I/O devices will be ported.
Testing and CI
In order to ensure that code changes do not break the port in the future, a Windows build-slave should be configured. This can either be a Windows VM or a wine/mingw-based Linux installation.
Windows uses some locale-specific paths and encodings. Codepage/encoding issues such as UTF-8/ASCII/UTF-16 conflicts should be investigated and fixed.
|POSIX Functionality||Done for MinGW, Visual C++ pending|
|Minimal build||Done for MinGW, Visual C++ pending|| Current configure options:
./configure --enable-python-libs --disable-e131 --disable-karate --disable-milinst --disable-renard --disable-spi --disable-stageprofi --disable-usbpro --disable-usbdmx --disable-uart
|Documentation||Done for MinGW, Visual C++ pending|
|Unit tests||Done for MinGW, Visual C++ pending|
|Network-based plugins||Done for MinGW, Visual C++ pending|
|Example programs||Done for MinGW, Visual C++ pending|
|Installer||not planned for MinGW, Visual C++ pending|
|MSVC support||optional / after GSOC|
|olad service||optional / after GSOC|
|Python interface||Done for MinGW, Visual C++ pending|
|Device plugins||optional / after GSOC|
|Testing and CI||optional / after GSOC|
|I18N issues||optional / after GSOC|