Programming Reference:Build System

From BCI2000 Wiki
Revision as of 14:13, 24 April 2018 by Mellinger (talk | contribs)

Jump to: navigation, search

Introduction

Early versions of BCI2000 (2.x and earlier) were dependent on the visual components library (VCL) by Borland and could only be built using the Borland compiler. Since version 3.0, Qt has replaced the VCL because it is not only compiler-independent, but also platform-independent.

To support many platforms and compilers, BCI2000 is using CMake http://www.cmake.org to generate Makefiles, project files, and Visual Studio solutions. CMake can be thought of as a meta-makefile; it examines your build environment and sets up a Visual Studio project, a Code::Blocks project, or a Unix Makefile which is custom tailored to your environment. Due to the wide variation in possible build environments, BCI2000 can not come with a fixed Visual Studio solution file, or a fixed Eclipse project file (such fixed solutions would always end up costing users a lot of effort). Thus, the number of platforms BCI2000 supports is mainly limited by the number of platforms and compilers for which CMake has generators.

Supported Environments

  • Supported Operating Systems
    • 32 and 64-bit Windows systems
    • Windows 7, 8, 10 (Vista not recommended)
    • Support for Unix-like systems (macOS, Linux) is currently broken
  • Supported Compilers
    • Visual Studio 2012, 2015, 2017
  • Supported IDEs
    • Qt Creator
    • Visual Studio 2012, 2015, 2017

How To Build Using CMake

  1. Ensure that your compiler and IDE are installed on the computer. This means that Visual Studio is installed if you intend to use Visual Studio, or that MinGW and Code::Blocks are installed if you intend to use Code::Blocks as your IDE and MinGW as your compiler.
  2. Download and install a recent version of cmake (Version 3.11.0 at the time of this writing) from http://www.cmake.org/ - Add to path for all users.
  3. Go to the BCI2000/build directory and double-click the "Make ... .bat" file which best describes your intended platform. (for example, if you plan to use Visual Studio 2008, you would run the "Make VS2008 Project Files.bat"). These batch files will ask you a few questions about which parts of the BCI2000 distribution you want to make, and will then call CMake with the appropriate options.
  4. Wait while cmake examines your computer, finds Qt and your compiler, and generates applicable project files for your system
  5. Open the generated project/solution (for Visual Studio, this is called "BCI2000.sln") in the IDE of your choice. Or, if you are using MinGW make, run the make command from the command prompt using the Makefile in the top-level "build" directory. Refer to your IDE's help for IDE-specific instructions on how to build an application.
  6. Even though CMake must always be run from one top-level place (the "build" directory), and will spend several seconds generating a Makefile or project file for the whole BCI2000 tree at once, this does not mean that you have to compile all of BCI2000 at once. In the next step, if you're using MinGW-make on the command-line, you could for example type "make Operator" or "make SignalGenerator" to build only selected modules (again, you should be in the top-level "build" directory when you do this). Visual IDEs usually have their own equivalent of this: for example, in Visual Studio 2008, you can right-click on a particular module and select "Build".
  7. If you build the targets"NewBCI2000Module" and "NewBCI2000Filter", this will create two new binary executables with these names. They will be found in the top-level "build" directory (and, in common with CMake and make, they should be launched only from this location). Launch NewBCI2000Module to create a new project in order to compile your own custom module. Launch NewBCI2000Filter to create a new filter and add it to a project you have already created. In either case, you may need to re-run CMake (step 3) in order to ensure these changes are reflected in the project file.

Building against a Qt distribution outside the BCI2000 source tree

BCI2000 comes with a stripped-down, precompiled version of Qt, which is downloaded by CMake at configuration time. This is a static version of the Qt libraries, and allows to distribute the resulting executable without hindsight to DLL dependencies. The complex and annoying implications of such dependencies has been termed "DLL hell" for good reasons, so we strongly recommend linking against the BCI2000-specific Qt libraries for Windows builds.

When running CMake, it determines the current compiler/OS combination, and tries to download an appropriate version of the BCI2000-specific Qt build. If no such build is available, it expects a local Qt installation to be available, and fails with an error message if this is not the case.

If a BCI2000-specific Qt build is available for the current configuration, you will still have the option of using a locally installed version of Qt. This is a CMake option USE_EXTERNAL_QT appearing in the CMakeCache.txt file after CMake has been run for the first time. Such options may be changed using the CMake GUI, or a text editor. After changing the option, run CMake again to apply the change to the created project files.

How To Test

It is important - especially if you're using an unsupported compiler/IDE - to test your executables once they've been built to make sure they function properly.

To run testing:

  1. Ensure that the entire BCI2000 project has built successfully and that executables exist in the BCI2000/prog directory, the BCI2000/tools/cmdline directory, and the BCI2000/build/buildutils/test directory.
  2. Run TestExecutables.bat in the BCI2000/build/buildutils/test directory. (This is a cross-platform script, and may be run on non-Windows platforms as well, provided that it is run from the directory in which it resides.)

The tests will run and report a message after they've finished whether they've failed or not. You may see a message in the beginning of the test stating that a directory does not exist. This is normal behavior and does not reflect whether or not your executables have failed testing or not.

A Note on found differences: differences may not indicate that you have a broken build. Sometimes different compilers handle the precision of floating point numbers differently than others. These can account for small differences in calculated signal or state values. The default reference files were generated using an MSVC build on 32 bit Windows. If your compiler is different, this may not be a problem.

Known Issues

  • MinGW, Borland and other single configuration generators within CMake only generate one configuration at CMake Run-time. By default, this is set to the release configuration. It can be set - along with specific compiler options - in BCI2000/build/cmake/BuildConfigurations.cmake. The Visual Studio generator will ignore settings in this file. To turn on a debug build in a single configuration generator, run cmake -i in the build directory and set CMAKE_BUILD_TYPE to "Debug" when prompted.
  • All Compilers handle non standard characters, such as umlauts and characters with accents or tildes, differently. Because BCI2000 currently has no standardized way of handling non standard characters in a cross-compiler environment, it is strongly recommended that - for the time being - special characters are not used in localizations during the development of BCI2000 Ver 3.0.

Conclusions

Now that BCI2000 is open to a number of platforms, and compilers, support may not exist for every possible compiler/platform available. Certain compilers do not optimize code as well as others, and this behavior may lead to poor system latencies during BCI2000 experiments. The supported compilers have been rigorously tested and confirmed to be adequate for compiling the BCI2000 sources. If you wish to use a different compiler, be sure to run tools/BCI2000Certification in order to confirm your setup. CMake is a powerful tool, but in the end, ability to compile the sources is completely up to the IDE/compiler choice. If your IDE/compiler choice is not listed above, it is strongly urged that you to consider using one which is supported. If you run into problems using an unsupported IDE/compiler combination, you can try to find help at the BBS - http://www.bci2000.org/phpbb/index.php. BCI2000 should compile as effortlessly as possible on supported platforms.

Windows platforms tested successfully so far

Compiler OS Processors Qt linkage
MSVC2008 Win XP SP3 2 static
MSVC2008 Win XP SP3 1 static
MSVC2008 Win 7 32bit 1 static
MSVC2008 Win 7 64bit 1 static
MSVC2010 Win XP SP3 1 static
MSVC2010 Win XP SP3 1 dynamic
MinGW > 4 Win XP SP3 1 static
MinGW > 4 Win XP SP3 1 dynamic

Status on other OSes

Note that the Qt libraries provided in the BCI2000 source tree are for Windows only, so you need to separately install Qt on your system before compiling BCI2000.

Linux

Executable tests are passed on x86 and amd64 architectures running Debian Squeeze (currently "Stable") and Wheezy (currently "Testing").

OS X

BCI2000 builds successfully in OS X Leopard and Snow Leopard using the CMake generating script at build/Make Unix Makefiles.sh. Executable tests run successfully on OSX, both in 32 and 64 bit mode.

See also

Programming Reference:Building Qt for BCI2000