Multiplatform IDE - c++

I recently realized I'm making it unnecessarily hard on myself to use 4 different IDEs, for every combination of (develop on Windows, develop on Linux)x(program runs on ARM, program runs on local x86 PC).
Currently, every time I switch between an ARM project and a x86 project (often a console app to pre-calculate lookup tables for the ARM project), I switch between IDEs.
If I already have YAGARTO installed on my Windows PC, what's the best way to set up (another?) Eclipse CDT to compile C++ code natively for my PC?
Is it better to somehow install 2 copies of Eclipse CDT, one set up to create ARM binaries, the other set up to create x86 binaries? How?
Is it better to install Eclipse CDT once, then somehow tell it to compile this project into an ARM binary, and that project into a x86 console app? How?
Is there some other IDE that understands that different projects run on different CPUs? What?
( Multiplatform C++ cross-compiler talks about building multiple cross-compilers. But I'm missing the next step: Once I have a few cross-compilers built, how do I hook an IDE up to them?)

You can switch toolchain configurations within Eclipse based on targets or projects. There's no need to switch IDEs, it's just a matter of associating toolchains correctly.
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Freference%2Fcdt_u_prop_build_toolchain.htm
http://www.frozentux.net/2008/10/switching-gnu-toolchains-in-eclipse-the-easy-way/
http://eclipsebook.in/c-cpp-development/building-code/build-eclipse-managed/

Related

How to use QtCreator on Windows to build and debug applications for Linux?

I am Windows developer accustomed to Visual Studio Community. Now I'm starting to develop for Linux on both embedded devices (Raspberry Pi, C.H.I.P) and PCs.
I have found that Visual Studio has two options to develop for Linux:
VisualGDB - Visual Studio extension for cross-compiling and remote debugging, but it costs too much for my current budget
the brand new Microsoft extensions: Visual C++ for IoT Development and Visual C++ for Linux Development, but they are buggy, they copy every file on every build and they are difficult to configure "Linux way" (no full make/cmake support, must use absolute include paths on remote machine) and also Intellisense does not work reliably.
So I'm ready try something less restricted than Visual Studio but with somewhat similar quality and workflow, and my current best option seems to be QtCreator.
How do I achieve building for Linux from QtCreator running on Windows machine
Which approach is supported or works better (provides auto-complete and debugging conveniences) with QtCreator - cross-compile & copy binaries and launch GDB, or building the project remotely (but with option to not copy files, in case I'm building on a Samba shared folder)?
Which approach is supported or works better (provides auto-complete
and debugging conveniences) with QtCreator
Given that you say the cross toolchain is not a problem, my biggest parameter for the choice would be the size of the project and compile time. If it's a project that you can cross build in few minutes I would go for the local option.
A few notes on the prerequisite when cross compiling:
You should have a sysroot of the device your cross-compiling to which from which the linker will get all the appropriate libraries that aren't dynamically linked.
When remote debugging, I found the following a best practice. You have to have two debugging apps, gdb and gdbserver. Gdbserver is run on the embedded device while you're running gdb on the host machine. To be able to step through the code at runtime, you need to cross compile with debugging symbols. If the device has sufficient memory, you can deploy the whole binary with debugging symbols on the device.
This is a big topic :) I suggest you ask subquestions so we can form the answer step by step.

Use GCC on Linux to cross-compile Qt apps for Windows

Ideally, I want to compile our QT-based apps, which also link other third-party libraries, on 64-bit Linux using GCC, but for a 64-bit Windows target. Again ideally, I want the result to run on 64-bit Windows without any additional runtime support, just as if we had compiled the same source code in Visual Studio. Is this possible with MinGW-w64?
I have successfully used MinGW-w64 to compile simple apps with GCC on Windows. I'm not sure how much of the MinGW-w64 installation is runtime support for executables as opposed to support for the GCC compilation environment. I did attempt to run a WinGW-w64 hello world executable on an installation of Windows without MinGW-w64, but had missing dll errors. This tells me that some runtime support was necessary, but I would like to know more precisely what is required.
If you don't want to install Windows, I think the best way is using a Virtual Machine. That's because even if the source code compiles for Windows, how could it be verified to run? You will need a real target environment to finally test your application.
From a complexity point of view, I think setting up a Windows machine (VM or not) and the necessary environment for Qt is a whole lot simpler than cross compiling bug hunting afterwards.
You can install Qt on the installed Windows, copy your project there, compile it and see the results in the real environment. This way you can cope with the minor differences when porting from one OS to another easily.
Nothing stops you from developing on Linux. You can do the entire development on Linux and just test the code on the prepared Windows by compiling and running. Sending the code to the Windows environment is simple by using git. The development process can be like :
Make a repository of your application, clone the repository both on Linux and Windows
Do the Major development on Linux and push
Pull on Windows from time to time, compile, test and make minor fixes and then push

Convert Unix Executable to Windows Executable

I compiled and ran a C++ program using Eclipse on my MacBook Pro. I now need to convert the Unix executable to a windows executable. How do I go about this? Specifally, how do I get this code to run on a Windows machine from the command prompt?
The only way you can get the unix executable to run on a Windows system is using a virtual machine (Something like VMWare or VirtualBox). This isn't REALLY running it on Windows, of course, it's setting up a UNIX system on Windows and running it on that UNIX system.
The executables (and the needed runtime environment) are vastly different between the two systems, you can't just run executables from one on the other.
Your only other option is to setup Eclipse on your Windows system and compile the application there.
You cannot "convert" an executable, you need to recompile for your target system. If you are using a GCC toolchain that is set up for Eclipse and there is no Mac specific code, it should be as easy as moving the project over, setting it up in Eclipse, and recompiling it. If that is too much of a hassle, you can consider setting up a Makefile and using MingW or Cygwin, or even Visual Studio if you'd like. If there is Mac specific code, then you need to look up the appropriate Windows documentation, or use something cross-platform like GTK+ or Qt.

Queries on Cross compiling, from Windows to Linux and from Linux to Windows,

I am working on a C, project which uses ffmpeg library.
Currently I'm working on windows platform, and I'll be cross compiling the project for Linux ARM.
With that background, I have few basic questions.
If I use ANSI C++, I can be sure that, I'll be able to cross compile the project using corresponding compilers [ MSVC, MingW ]
But ..
If I'm using "Win32" and other "Windows" specific APIs in my project, how does the cross compiler will handle it, to make the project able to run on Linux.
Similarly, If I'm using Linux specific "features" in my project, how does the cross compiler will handle it, to make the project able to run on Windows.
When you cross-compile, the code that is being cross-compiled must use APIs that are available on the target platform (ie, the one that it will eventually run on). A cross-compiler does not magically give access to Win32 APIs when its output is run on a Linux machine; it is the same as compiling the code on the target machine, but means you don't need to actually do so. You could achieve the same thing, in other words, by just running a native (non-cross) compiler on an ARM Linux box, but you'd need a powerful enough ARM box to run the compiler.
That said, in principle, you could cross-compile to Linux while using winelib to provide win32 APIs. Not sure how well it works on ARM though - it's only really meant to be used on x86.
Finally, note that cross-compiling tends to be quite complex even in the best of times. It may make your life simpler to cross-compile from x86 Linux to ARM Linux instead of x86 Windows to ARM Linux - while it's possible to do cross-OS and cross-platform builds, the less variables you have changing the simpler things will be.
If you use Winapi, your project will not be able to run on Linux.

Eclipse CDT: From Windows to Linux

I have eclipse installed on windows and use cygwin to develop programs for linux. I compile using the cygwin toolchain and I also do my tests on cygwin.
Now I would like to compile my program also with the native linux toolchain and I also would like to debug it from the windows machine.
Is something possible with Indigo SR2? What is the best way to accomplish this?
I found this but then I would have two projects one for windows and one for linux. I would like to have just one project for both platforms to avoid syncrhonizing the sources back and forth.
Thanks.
I guess you want a cross platform development environment.
There are various tools for the job, but my choice would be CMake. Basically, you will write CMakelists.txt file instead of Eclipse .classpath and .project files, and generate those files with cmake executable. But in details, you will need to overcome some difficulties which are inherent in cross platform development.
I have successfully created more than one project with these tools, and they currently under a heavy load.