There appears to be an error in the Wiki instructions for creating a MS Visual Studio project for LMS7Suite using the CMAKE GUI. The instructions on the Wiki call for a wxWidgets directory and files that are not available from wxWidgets. I have tried wxWidgets 3.1.0 that is called for in the instructions. I also tried wxWidgets 3.0.2 since this is shown as a stable release. Can anyone help? Has anyone successfully created a project for Windows?
Paul Oxley
oxleys@att.net
I have a cmake-based build for the PothosSDR installer that builds both LimeSuite and WxWidgets. The wx widgets is built for static linking so there are no wx files to install. Perhaps you can borrow some of the configuration flags used:
Here is the section that builds wx widgets. It just clones and MSbuilds the project:
Here is the build for limesuite, there are several wxwidgets flags passed in:
https://github.com/pothosware/PothosSDR/blob/master/BuildLimeSuite.cmake#L18
Josh
It would be helpful if someone updated the instructions that are shown on the wiki. http://wiki.myriadrf.org/Lime_Suite
They need to be tested on a Windows system that is clean to prove that they work.
I will be building the wxWidgets source code. Apparently, the binary install doesn’t create the needed object file for the linker.
Paul
I had trouble with the binaries from wx. There were multiple packages for development files, libraries for development, runtime libraries, debug, release, etc. I couldn’t not find the combination I was looking for (release mode static/or release mode dll would have done it for me), so I ended up building from source. I could be wrong, but building from source ended up being reliable in this case.
The wiki screenshot is from a build on my PC. I ended up building wx with visual studio, and the only thing that might be a bit odd is that the vc140_x64_lib directory was my doing: I renamed vc_x64_lib to vc140_x64_lib and vc120_x64_lib respectively so I could have both versions of VC coexist.
I’ve been successful following the wiki instructions and using the “For Developers” paragraph the latest wxwidgets release instructions:
Josh, when I execute either the buildall or LimeSuite solution in the resulting VS solution file, it builds a .lib for LimeSuite, but not an executable for the app. Three other executables are built. I see lms7suiteApp.cpp in the CMakeLists.txt for the LimeSuite solution. Where is the specification for the executable? Thanks.
Looking at the cmake output, it looks like it’s not finding wxwidgets even though I’m specifying -DwxWidgets_INCLUDE_DIRS -DwxWidgets_LIBRARIES and -DwxWidgets_ROOT, so it’s disabling LimeSuitGUILMS7.
I will report back once I have that straightened out.
The CMake complete command line example for step 4.2 is sensitive to the ROOT_DIR values. If they are incorrect, the LIB and INCLUDE_DIRS values are ignored and LimeSuiteGUILMS7 won’t be built. I turned that command line section into a .bat file since I ran it so many times while troubleshooting.
Then I had trouble with the wxwidgets precompiled binaries. I couldn’t get the correct static libraries to link to the limesuite executable nor did having the dynamic dll files available work; there was confusion at runtime looking for “u” and “ud” libraries simultaneously. So I went the route Josh indicated and compiled wxwidgets from source. I found I could change wxWidgets_USE_STATIC in LimeSuite’s src/CMakeLists.txt to ON or OFF depending on whether I wanted to include statically built wxwidget libraries or use dynamic ones. When building wxwidgets, the MS VS Studio build configuration is ‘Release’ for static, and ‘DLL Release’ for dynamic; Platform --> ‘x64’ .
Edit: As a new user, I can’t reply again to this thread.
@joshblum a static checkable option would be fine. The cmake file is already well-organized and thought out.
@tony.bigbee Thanks for reporting back. That feels a like my experience as well. In my opinion, the FindwxWidgets.cmake scipt that comes with cmake was a little finicky and hard to debug, and I think it could do a better job being automatic. Its given me some fuss on other wx projects as well 
I found I could change wxWidgets_USE_STATIC in LimeSuite’s
src/CMakeLists.txt to ON or OFF depending on whether I wanted to include
statically built wxwidget libraries or use dynamic ones.
The main reason to use static libraries by default is to reduce the number of dlls that need to be installed for runtime. However, wxWidgets_USE_STATIC could become a checkable option that could be set in the GUI or command line if that would be useful?
set(wxWidgets_USE_STATIC ON CACHE BOOL "dynamic vs static libs")
Josh
From my experience, a static library would be preferable on a performance basis also. The DLL approach would be bound to the logic at run time. The static would already be built into the main code logic by the link process with the build. One might want to use a DLL if they wanted the logic to operate in a different string on the processor.
Paul