Getting Started

Required Setup

To get started, you will need to download two common utility programs:

• git - command line source control and interface to GitHub so we can download and keep up-to-date with MEL's source code
• CMake - command line tool to generate platform, compiler, and hardware specific build files or workspaces from MEL's source code

When installing git, all options can be left at their default. When installing CMake, be sure to check the option which adds it to the PATH system variable. Afterwards, ensure that both programs have been added to the PATH system variable by opening a terminal anywhere and attempting to run them:

> git
> cmake

If either program is not found, manually add it to the PATH by navigating to: Control Panel -> System and Security -> System -> Advanced system settings -> Environment Variables. Under System variables, edit PATH to include the lines:

C:\Program Files\Git\bin
C:\Program Files\CMake\bin

Cloning MEL with Git

The first step to using MEL is, of course, downloading all of it's source material. Open a terminal in the location you wish to keep MEL (the recommended location is C:/git/) and run the following git command:

> git clone https://github.com/mahilab/MEL # make local copy of MEL repository

git will download a local copy of all of MEL's source code to your computer. Changes you make to this copy are your own, and will not affect the master repository unless they are submitted for a pull request and accepted.

What is CMake?

MEL uses a very popular tool called CMake to handle the automatic generation of C/C++ build files from MEL's source code. These "build files" could be a number of things, such as a Make makefile, a Ninja build.ninja file, or a Visual Studio .sln solution file. Which type of build files are generated depends on the target hardware and/or compiler being used with MEL. For example, when using Quanser hardware, MEL must be compiled with MSVC, so we use CMake to generate a Visual Studio solution from MEL's source files. Likewise, when using NI RT Linux hardware, MEL must be compiled using NI's GNU-based cross-compiler which cannot be built with Visual Studio, so we use tools like Ninja or Make. Note that the logic and options CMake uses to generate build files are all located in a single file in MEL's root called CMakeLists.txt. You shouldn't ever need to modify this file directly.

The following table informs which generator should be used depending on your target hardware and compiler:

Hardware	CMake Generator	CMake Option
QuanserDAQs	Visual Studio 15 2017 (Windows 32-bit) Visual Studio 15 2017 Win64 (Windows 64-bit)	QUANSER
NI myRIO	Ninja (Windows/Linux host) MinGW Makefiles (Windows host) Unix Makefiles (Linux host)	NI_ARM
NI cRIO	Ninja (Windows/Linux host) MinGW Makefiles (Windows host) Unix Makefiles (Linux host)	NI_X64
Myo	Visual Studio 15 2017 (Windows 32-bit) Visual Studio 15 2017 Win64 (Windows 64-bit)	MYO
XInput	Visual Studio 15 2017 (Windows 32-bit) Visual Studio 15 2017 Win64 (Windows 64-bit) Ninja (Windows) MinGW Makefiles (Windows)	XINPUT

In addition to hardware specific options, there are a few generic options you may wish to keep in mind:

CMake Option	Effect
MEL_STATIC	Builds MEL as a static library (see bottom for details)
DISABLE_LOG	Disables MEL's built in error logging system
EXAMPLES	Builds MEL example applications
TESTS	Builds MEL unit tests
MOVE_BINS	Moves compiled binaries to top level of MEL in conventional bin and lib directories
BUILD_DOC	Builds MEL's HTML documentation (Doxygen must be installed)

Detailed guides for using CMake to generate your build files can be found at the following links:

• Building MEL for Quanser (Q2-USB, Q8-USB, QPID)
• Building MEL for NI RLT Linux (myRIO, cRIO)

Dynamic vs Static Compilation

By default, MEL is built as a dynamic library. On Windows, this is a .dll file, and on Linux it is a .so file. There are many reasons for this. First and foremost, MEL necessarily requires linkage to several external API libraries from different hardware vendors. By building MEL as a dynamic library, these libraries are bundled directly into MEL, meaning all you have to do is link you application against MEL. If you were to instead build MEL statically, you would also have to link your program against these external libraries, of which there may be several to keep track of. A second reason is that you will most likely use MEL for several different projects. Dynamic linkage allows you to share MEL.dll between all your projects and keep compile times and sizes at a minimum. Third, should the implementation of MEL functions change, you do not need to recompile your project; you simple need to swap the MEL.dll for the most recent version.

Of course, there are reasons you may want to compile MEL statically. For instance, if you want to keep your application to a single executable and require no dependency on MEL.dll you would link statically. Also, because there is some runtime overhead to linking dynamically, you may choose to compile statically if you are concerned with code execution and/or loading times (though the difference is likely imperceptible).

Note: If you choose to compile and link MEL statically, you will need to read through MEL's CMakeLists.txt to figure out which libraries MEL is linking against, and link against these in your own application. In addition, your project MUST define the preprocessor variable MEL_STATIC (e.g. by adding add_definitions(-DMEL_STATIC) to your own CMakeLists.txt).