About | Install | Build | API | Tests | License
The LabPack-C project is a LabVIEW-friendly C library for encoding and decoding MessagePack data. The library is intended to be used with the Call Library Function node. This provides MessagePack encoding and decoding functionality to LabVIEW as a Dynamic Link Library (DLL, Windows), Dynamic Library (Dylib, macOS), and/or Shared Object (SO, Linux).
A single ZIP archive containing the pre-compiled/built shared libraries for all of the platforms listed in the Build section is provided with each release.
- Download the ZIP archive for the latest release. Note, this is not the source code ZIP file. The ZIP archive containing the pre-compiled/built shared libraries will be labeled:
labpack-c_#.#.#.zip, where#.#.#is the version number for the release. - Extract, or unzip, the ZIP archive.
- Copy and paste all or the platform-specific shared libraries to one of the following locations on disk:
| Platform | Destination |
|---|---|
| Windows | C:\Windows\System32 |
| macOS | /usr/local/lib |
| Linux | /usr/local/lib |
| NI Linux RT | /usr/local/lib |
Ensure all of the following dependencies are installed and up-to-date before proceeding:
- CMake 3.9.x, or newer
- Microsoft Visual C++ Build Tools 2017, Windows Only
- XCode Command Line Tools, macOS Only
- Git
- C/C++ Development Tools for NI Linux Real-Time, Eclipse Edition 2017, NI Linux RT only
- Doxygen, Documentation only
The Microsoft Visual C++ Build Tools 2017 should have installed a x64 Native Build Tools command prompt. Start the x64 Native Build Tools command prompt. This ensures the appropriate C compiler is available to CMake to build the library. Run the following commands to obtain a copy of the source code and build both the 32-bit and 64-bit DLLs with a Release configuration:
> git clone https://github.com/fieldrndservices/labpack-c.git LabPack-C
> cd LabPack-c
> build.bat
The DLLs will be available in the build32\bin and build64\bin folders.
Ensure the command-line tools for XCode have been installed along with git before proceeding. Start the Terminal.app. Run the following commands to obtain a copy of the source code from the repository and build the dynamic library (dylib):
$ git clone https://github.com/fieldrndservices/labpack-c.git LabPack-C
$ cd LabPack-C
$ mkdir build && cd build
$ cmake ..
$ cd ..
$ cmake --build build --config Release
The dynamic library (.dylib) will be available in the build/bin folder.
If running on Ubuntu or similar distribution, ensure the build-essential, cmake, and git packages are installed before proceeding. These can be installed with the following command from a terminal:
$ sudo apt-get install build-essential cmake git
Start a terminal, and run the following commands to obtain a copy of the source code from the repository and build the shared object (so):
$ git clone https://github.com/fieldrndservices/labpack-c.git
$ cd labpack-c
$ mkdir build && cd build
$ cmake ..
$ cd ..
$ cmake --build build --config Release
The shared object (.so) will be available in the build/bin folder.
NI provides a cross-compiler for their Real-Time (RT) Linux distribution. Before proceeding, download and install the C/C++ Development Tools for NI Linux Real-Time, Eclipse Edition 2017. It is also best to review the Getting Stared with C/C++ Development Tools for NI Linux Real-Time, Eclipse Edition guide for more general information about configuring the internal builder.
- Start NI Eclipse. A Workspace Launcher dialog may appear. Use the default.
- A welcome screen may appear after the application has loaded. Close the welcome screen.
- Right-click in the Project Explorer on the left and select Import from the context menu that appears. A new dialog will appear.
- Select
Git->Projects from Gitfrom the dialog that appears. Click the Next > button. A new page will appear. - Select the
Clone URIfrom the list that appears in the new page of the dialog. Click the Next > button. A new page will appear. - Enter the URI for the git repository in the URI: field, i.e.
https://github.com/fieldrndservices/labpack-c.git. The Host: and Repository path: fields will populate automatically. Click the Next > button. A new page will appear. - Ensure only the
mastercheckbox is checked in the Branch Selection page of the Import Projects from Git dialog. Click the Next > button. A new page will appear. - Browse to the workspace directory for NI Eclipse to populate the Directory: field. Leave all other fields as the defaults. Click the Next > button. A new page will appear.
- Select the
Import existing projectsradio button from the options under the Wizard for project import section. Click the Next > button. A new page will appear. - Click the Finish button. No changes are needed on the Import Projects page. A new
labpack-cproject should appear in the Project Explorer. - Click the Build toolbar button (icon is a small hammer) to build the NI Linux RT x86_64-based shared object (so).
- Click the drop-down menu next to the Build toolbar button and select the
ARMbuild configuration. This will build the NI Linux RT ARM-based shared object (so).
Note, steps 3-10 only need to be done once to setup the project. The liblabpack-rt.so will be located in the x86_64 folder under the project's root folder inside the Eclipse workspace folder, and the liblabpack-arm-rt.so will be located in the ARM folder under the project's root folder inside the Eclipse workspace folder.
Doxygen is used to build the Application Programming Interface (API) documentation. Ensure the latest version is installed then enter the following command from the root directory of the project to build the API docs:
$ mkdir -p build/docs/html
$ doxygen docs/Doxyfile
The output will be in the build/docs/html folder of the root directory of the project.
All of the tests are located in the tests folder. The tests are organized in "modules", where an executable is created that tests each source "module", i.e. writer, reader, etc. The tests are separated from the source, but the tests are built as part of build for the shared library. Each test executable is located in the bin\tests folder of the build directory and they can be run independently.
If the ctest, or make test on non-Windows systems, commands are used after building the tests to run the tests, then the ctest test runner framework is used to run the tests. This provides a very high level summary of the results of running all tests. Since the tests are organized into "modules" and suites, the ctest command only indicates that a test within a module and suite has failed. It does not indicate which test has failed. To investigate the failed test, the executable in the bin\tests folder for test module should be run. For example, if a test in the writer module failed, the ctest test runner will indicate the "writer" test has failed. The bin\tests\writer executable should then be run as a standalone application without the ctest test runner to obtain information about which test and assertion failed.
Start a terminal command prompt and navigate to the root folder of the project. Note, if following from the Build instructions, a command prompt should already be available at the root folder of the project. Enter the following commands to run the tests:
> ctest -C "Debug"
Or
> bin\reader
> bin\writer
> bin\status
Start the Terminal.app. Note, if following from the Build instructions, the Terminal.app has already been started and the present working directory (pwd) should already be the root folder of the project. Enter the following commands to run the tests:
$ ctest
Or,
$ bin/tests/reader
$ bin/tests/writer
$ bin/tests/status
Or,
$ make test
Start a terminal. Note, if following from the Build instructions, the terminal has already been started and the present working directory (pwd) should already be the root folder of the project. Enter the following commands to run the tests:
$ ctest
Or,
$ bin/tests/reader
$ bin/tests/writer
$ bin/tests/status
Or,
$ make test
See the LICENSE file for more information about licensing and copyright.