some issues using cmake with visual studio for lsl app development

[dmedine]

Just thought I would report my experience in case anyone has time to deal with these little issues or experiences similar roadblocks.

I just had to make a few updates to the BrainVisionRDA and I experienced some non-ideal behavior from CMake. Everything worked pretty well in the end, but I had to do a few things by hand because CMake got it wrong.

First of all, I added cmake support for BrainVisionRDA. The behavior, when I do an in tree build is now identical as it is for LiveAmp, LabRecorder, etc. But, some of this might be due to dumb things that I did in my CMakeLists files.

First off, I have to do a little bit of tweaking to the 'input' field for the linker. When I specify 64 bit and use <path_to_qt5>\msvc2015_64 as my Qt5_dir, for example, the .lib files it points to are in given as <path_to_qt5>\msvc2015 which are obviously libraries with the wrong architecture.

I also don't know how to set the path to the desired lsl directory. I installed lsl in C:\lsl, but the project has some ../../blah_blah path to liblsl which might sometimes be there, but isn't at the moment.

These are minor inconveniences. The more disturbing thing is that after making some changes to the .ui file, I couldn't get the project to regenerate the machine generated qt files. I even tried erasing labstreaminglayer/build and regenerated the whole project, but it still didn't reflect the changes I made to the GUI. In the end I simply called moc and uic manually and added the generated files to my project.

[cboulay]

The more disturbing thing is that after making some changes to the .ui file, I couldn't get the project to regenerate the machine generated qt files.

Somewhere after the cmake project() line, you'll need to add set(CMAKE_AUTOMOC ON), maybe here.

This is supposed to create a prebuild command to regenerate the files before build (maybe have to clean build). However, sometimes this doesn't work in Visual Studio and it should create an autogen custom target for you to run manually.

First off, I have to do a little bit of tweaking to the 'input' field for the linker. When I specify 64 bit

What do you mean by "specify 64 bit" specifically? Is this during the cmake call? Are you using cmake command line or cmake-gui? (I find the latter doesn't always behave the same as command line version)

I also don't know how to set the path to the desired lsl directory.

Is this some directory where you've dumped the .bin, .h, .dll files, or is it the full sccn/liblsl tree, or something else?

[tstenner]

When I specify 64 bit and use <path_to_qt5>\msvc2015_64 as my Qt5_dir, for example, the .lib files it points to are in given as <path_to_qt5>\msvc2015 which are obviously libraries with the wrong architecture.

That's a problem of CMake and Qt, as they need the full path (<path_to_qt5>/msvc2015_64/lib/cmake/Qt5) and search for it (and find the wrong path) otherwise. It should get better in a few CMake versions.

I also don't know how to set the path to the desired lsl directory. I installed lsl in C:\lsl, but the project has some ../../blah_blah path to liblsl which might sometimes be there, but isn't at the moment.

The relative paths are entirely optional, when no lsl path is set but it's found in ../../blabla it's taken. At the moment, you can either set LSL_INSTALL_ROOT to a folder you set as install target / downloaded the archive to or set LIBLSLDIR to the source path (c:\somewhere\lsl\LSL\liblsl).
There have been few changes in the last few months to these options, still, I put all of it in a separate file you can just copy into a project and then include(Findliblsl.cmake) in the CMakeLists.txt.

The more disturbing thing is that after making some changes to the .ui file, I couldn't get the project to regenerate the machine generated qt files.

The CMAKE_AUTOMOC option is set in LSLCMake.cmake (which is included automatically when liblsl is included). Could it be that Visual Studio still relies on the solution file in that directory?

I've brought the CMake config in line with what I've found to work with less magic and outdated settings (e.g. the cmake_policys), could you check out the PR I've opened as I haven't got a windows machine at my hands?

[tstenner]

The more disturbing thing is that after making some changes to the .ui file, I couldn't get the project to regenerate the machine generated qt files.

I've found the problem; you need to #include "ui_mainwindow.h" so the compiler / CMake automatically picks up changes to the mainwindow.ui. I commited this in labstreaminglayer/App-BrainProducts@1727dd5 and it should work now.

As far as I can see, the BrainVision RDA client doesn't require any drivers so it should (in theory) run on Linux / macOS?

[dmedine]

Thanks for all the clarification. I will try playing around with some of these things when I have a chance.

It seems like Visual Studio and CMake don't get along very well together---which is not surprising given the complexity of Visual Studio.

When I say that I 'specify 64 bit' I mean that I am using cmake-gui and selecting msvc140 x64 as the configuration.

I should say that I am also misusing the intended workflow of the cmake environment, and this might cause some issues as well. I do an in tree configuration and then remove the liblsl and lsl_boost projects from the solution because I have already built them (and 'installed' in C:\lsl\lib\x86/64) and don't want to build them again, but rather do some development on an intended app. I want to build for both win32 and x64 and the property settings are inconsistent between these two configurations.

I don't really want to spend the effort making this seamless. I only do work on these apps about 2 times per year and in the future will completely abandon these connectors in favor of other software that connects to Brain Products amplifiers and streams via LSL. For now, I can at least make it work with minimal manual effort. I don't think that the current CMake structure will ever be able to deal with the LSL ecosystem in exactly the way that fits my workflow, but that's ok.

Also, yes, BrainVision RDA can build on Linux and macOS. There are no drivers. Just a tcp connection and LSL.

[agricolab]

Also, yes, BrainVision RDA can build on Linux and macOS. There are no drivers. Just a tcp connection and LSL

Point is server-side, as BrainVisionRecorder creates the RDA outlet - and BVR only runs on Windows, doesn't it?

[tstenner]

I should say that I am also misusing the intended workflow of the cmake environment, and this might cause some issues as well. I do an in tree configuration and then remove the liblsl and lsl_boost projects from the solution because I have already built them (and 'installed' in C:\lsl\lib\x86/64) and don't want to build them again, but rather do some development on an intended app. I want to build for both win32 and x64 and the property settings are inconsistent between these two configurations.

So far, I don't see anything out of the ordinary. As far as I see, you use CMake to create the VS solution files? The workflow should then be:

• build and install liblsl to C:\lsl32/C:\lsl64
• create two build directories for each apps (build_32/build_64) and create a solution files in them (cmake -DLSL_INSTALL_ROOT=c:\lsl32 -DQt5_DIR=c:\qt\5.12.0\msvc2015\lib\cmake\Qt5 -G "Visual Studio 14 2015" -A Win32 and cmake -DLSL_INSTALL_ROOT=c:\lsl64 -DQt5_DIR=c:\qt\5.12.0\msvc2015_64\lib\cmake\Qt5 -G "Visual Studio 14 2015" -A x64)

Building liblsl including lslboost takes less than 2 minutes on my laptop from 2013; in any case I suppose it's a lot faster than the workarounds you described above.

Also, yes, BrainVision RDA can build on Linux and macOS. There are no drivers. Just a tcp connection and LSL

Point is server-side, as BrainVisionRecorder creates the RDA outlet - and BVR only runs on Windows, doesn't it?

At the moment it builds only on Windows, but with some minor changes it should work on any OS (with a Windows host running Brainvision Recorder).

and in the future will completely abandon these connectors in favor of other software that connects to Brain Products amplifiers and streams via LSL

Sounds interesting, are these plans public yet?

[dmedine]

Recorder only runs on Windows because Brain Products amplifiers have drivers for Windows only.

[cboulay]

Hi David, I was recently updating the build instructions (docs now on readthedocs here), and the template app. I was also playing around with VS2019 while doing so.

VS2019's cmake integration is better than 2017's. One of the smallest but most helpful changes is that the default build directory is now out, so no more hunting in obscure folders to find your binaries. This makes populating your build folder with the required DLLs a little easier.

Also on that note, I added some POST_BUILD lines to my Tobii app and these seem to work well. See here

Now that this is all fresh in my mind, it would be very helpful if you could take a look at the instructions and the workflow and see if some of your pain points are removed and maybe we have a shorter path to making this a good workflow for you.

By the way, the "full-tree" build is now considered an expert-only feature. The preferred way to build an app, at least what we will try to keep up in docs and support, is to clone only that app, grab the necessary liblsl dll's from the liblsl release page, and specify liblsl's location as a cmake argument.

[cboulay]

Closing as stale. CMake support in IDEs has improved in the past 4.5 years.