Solved: Companion Next Compile under Cygwin Problem

A fork of eePe. It's aim is to provide one tool that works with ALL firmwares!
Post Reply
jtaylor
Posts: 170
Joined: Fri Nov 01, 2013 1:31 am
Country: -
Location: Wexford (Pittsburgh), PA

Solved: Companion Next Compile under Cygwin Problem

Post by jtaylor »

I have been using Cygwin to compile Companion on my Windows 7 laptop and running it and the Simulator under xwindows and that has worked fine (including sound in the simulator) up until the last few days, but something has changed that is causing me a problem. When I went to compile next yesterday I got a cmake error and discovered that there was a cmake change that required a feature in cmake 3.x and I was on 2.9.8.1 so I upgraded to 3.1.2 for Cygwin.

After the cmake upgrade cmake ran and companion (next) compiled. However, when I went to run simulator I got a dialog saying "Which radio type do you want to simulate" and there was only a close button and no radio types available for selection. And when I ran Companion, Companion came up and I could open a eepe file, but when I clicked on Simulate I got a pop up dialog saying "Simulator for this firmware is not yet available"

Attached is a screenshot showing both messages along with the commands used to run them.

I compiled the same next Companion and Simulator on my OpenSUSE13.2 desktop and it ran correctly with no problems. So something has changed that doesn't like my Cygwin on Windows environment, but I haven't been able to figure out what so any pointers on where to look would be appreciated.

Edit: Problem found

I found the problem. So for anybody else that might be compiling under Cygwin:
companion/src/simulation/simulatorinterface.cpp on next contains the following:

void registerSimulators()
{
QDir dir(".");
QStringList filters;
#if !defined __GNUC__
filters << "*-simulator.dll";
#else
filters << "*-simulator.so";
#endif
foreach(QString filename, dir.entryList(filters, QDir::Files)) {
registerSimulator(filename.prepend("./"));

since I'm compiling with gnuc __GNUC__ is defined.......but I'm compiling to run on Windows so it needs and creates dll's and not so's. As the program is looking for .so's and doesn't find any no simulators get registered.

My fix was just to remove the if !defined and leave only filters << "*-simulator.dll";

I would like to fix it upstream so I don't have to patch it every time it changes, but don't see a really clean way to do it. Will have to think about it a little.

Jim
Attachments
screenshot.jpg

User avatar
Kilrah
Posts: 11109
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Solved: Companion Next Compile under Cygwin Problem

Post by Kilrah »

Hmm why not build natively for Windows?
jtaylor
Posts: 170
Joined: Fri Nov 01, 2013 1:31 am
Country: -
Location: Wexford (Pittsburgh), PA

Re: Solved: Companion Next Compile under Cygwin Problem

Post by jtaylor »

Kilrah wrote:Hmm why not build natively for Windows?
Good question, and in the future I may. I started in the paper tape days and have worked with UNIX (AIX) after it came out, and I run Linux (OpenSUSE) on my Desktops and have had Cygwin installed on my Windows laptops for years to give me the UNIX commands and utilities with which I'm failure.

Before the Taranis was released and I wanted to take a look at the simu I had no problem setting up the build environment on Linux but I only had Cygwin and CodeBlocks with MinGW and WxWidgets on my laptop and I couldn't get simu built with the Fox Toolkit running on native Windows (it would come up, but keyboard input didn't work) so I started building it with Cygwin as an xwindows program and just running an xserver on Windows. And when I wanted to compile Companion on the laptop it just seemed easier to set up SDL, xsd, xincs, and the other requirements under my already working Cygwin environment than try to get it all working under native Windows.

I fly on the current stable (currently 2.0.15) and download the matching Companion on Windows and compile next, and compile both the current stable (for production) and next (for test) on Linux. Actually doing it this way on Windows lets me run both Companions at once so I can compare features and changes without any chance of next affecting my stable because next uses my Cygwin home directory and the Windows Companion uses the registry and my \user.

Post Reply

Return to “companion9x”