I have found that using MSVC to write C++ code and push to Linux to debug works fairly well for a simple environment where you just take the default gcc, cmake, etc.
But, does anyone know how to control the version of gcc, cmake, etc? Depending on the situation I may need to target several different compilers. Has anyone had any luck controling the core toolchain from MSVC?
It would be great if there is a way to just set up different build configurations.
Related
I'm setting up a cross platform build environment. For that reason I've chosen to go for clang, for the, correct me if I'm wrong reasons:
Using the "same" compiler for different platform would potentially reduce the quirks that arise when getting gcc code to work with MSVC
Clang with its MSVC compatible ABI would let me work with the WINAPI as if I were using MSVC.
My question is: How do I get CMake to, based on the platform, find the correct clang to use, that is clang-cl in Windows and clang on *nix platforms ?
Please note that I'll be using Ninja generator for CMake, and the project is Qt based, if that matters.
You (the project author) don't get to choose the compiler, the user that invokes CMake chooses the compiler.
The only thing you can do from within the CMakeLists is abort with an error if you are not happy with the choice that the user made.
There are a couple of ways how the user can specify to CMake which compiler to use. Popular examples include setting the respective environment variables, passing it via -DCMAKE_CXX_COMPILER on the first CMake run (and only on the first run; you cannot change this later without re-configuring from scratch!), or by using a toolchain file.
On Visual Studio, you can also use the -T option to select a build toolchain. This allows you to build with clang from Visual Studio.
You should document in your project's Readme which compiler you expect your users to configure for CMake and maybe give them a small example how to do this via one of the methods above.
My task is to create a C++ SDK - in the form of a dynamic library(s), most likely.
It is supposed to be used on different platforms - Windows (32/64 bit), Linux (32/64 bit), Mac OS, Android and iOS. I don't have much experience with multi-platform project setup and I'm trying to decide what methods and tools to use for easiest development and deployment.
Side note: I will also have to prepare automatic builds (jobs) on Bamboo CI server, in order to run compilation and tests for each required target.
My main dilemmas are:
Project setup. Should I prepare different project schemas for use on different platforms (like .sln on Windows and makefiles on Linux), or maybe try using a tool like CMake? Is it even possible to prepare a CMake project that will suit all these target platforms?
Compilation toolchain. Should I use "native" C++ compilers for every platform (like MSVC on Windows and GCC on Linux), or maybe a single toolchain like Clang + LLVM? Would Clang + LLVM (and some linker obviously) be even able to build distributable binaries for all these platforms I need?
Development Environment. Which OS/IDE would be best for working on that kind of project? I prefer working on Windows and my usual IDE is Visual Studio - would it be viable in this case, or maybe something else would be more appropriate?
I know that my problem is very complex and there is no straight answer for any of these points, but every advice and even partial answer will be much appreciated :)
As you say, there is no one-size-fits all solution, so I will make some general suggestions. Feel free to pick-and-choose as you feel is most beneficial.
If you plan to do your building on the host OS, cmake sounds like exactly the tool for you. It self-describes as a "build system generator", where the steps to build on a specific host OS are abstracted away, meaning the same setup "should" work for any system cmake supports.
If you're thinking of cross-compiling, you're in for some hurt with the iOS and MacOS goals. As far as I know, and I have put some effort into trying, Apple does not release compilers for their systems that do not run on their systems -> You will have to compile for iOS and MacOS from a MacOS computer. If you can prove me wrong on this point, I would be glad to hear it :)
Depending on your licensing requirements, if you really want an overkill solution you could look into Qt* and qmake. I have had excellent luck with their multiarchitecture solutions, and Qt supports all of the systems you listed in your original question. I find Qt + qmake far easier to deal with than cmake.
* Yes, Qt does non-GUI work quite well too!
I touched on this in the second point of 1., but my general suggestion would be to use native toolchains. Excluding MacOS, it's easy to set up Virtual Machines, build server, etc. to build native code, and my experience with cross-compilers is they always add another layer of heartache, even worse than having to remote-access a separate builder computer.
Provided you avoid system-dependent headers, libraries, or extensions, it shouldn't matter what system you use. Things like <windows.h> and <linux/*.h> are obvious, but the best way cross-platform compatibility can be verified is by testing the foreign systems as often as possible.
Agnostic of compiler used, I would suggest turning on all the warnings. They are usually important, and may indicate a place where the compiler was able to band-aid over a problem but trying to compile for another system will blow up. If you're working on a team, it might be a good idea to set warnings to result in build errors to make sure the rest of the team is as rigorous as you are.
I don't know about LLVM or MSVC, but GCC will give you some hints as to platfom-specific extensions if you give it the -pedantic and -ansi flags. As explaind here, those flags tell GCC to warn for any GNU-specific extensions.
You are very likely going to need multiple tool-chains (you mention C++ and it has no ABI so to be usable on Windows you are more or less required to build with CL). It follows that you will not be able to use a single vendor-specific project setup. As the project grows maintaining multiple versions of project files becomes quickly untenable so your choice of build system is critical. Have a look at Shake and compare to alternatives with a similar feature-set. The choice of IDE is of less importance - many programmers prefer their favorite editor (Emacs or Vim) and may need to do work on any of the supported platforms.
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.
I have the source code for some very simple command line programs. I was considering the option of compiling them on a Linux machine (they were deveoped here) so they can be used on Windows. If I am not wrong this is called Cross-compiling. I have never tried it, but reading yesterday some information, it seems to be kind of complicated or not successful. I would like to hear about your opinions, and how could I port a simple "hello world" program, which compiles on Linux with g++.
Thanks
Look into mingw, a suite of tools for building Win32 applications in Linux. If the programs don't depend on any Linux-specific functionality not supported by mingw, you should be fine.
Note that cross-compilation is not the same thing as cross-platform. With cross compilation, you compile the code to a Windows executable on the Linux box, then transfer the executable to a Windows box. With cross-platform, you transfer the source code to the Windows box and compile to a Windows executable using a Windows compiler.
The former is quite difficult (but not impossible), the latter is very easy, using a compiler such as MinGW, a others have mentioned.
I cross-compile on a daily basis. But I don't set up cross-compilers on a daily basis. It can be tricky, but it's certainly possible.
As long as you use standard C++ your code will be cross-platform. You can also use cross-platform libraries like STL, boost, Poco, Qt, etc...
Only when you start to use platform specific code you lose portability. For example including <windows.h> will make your code only compilable on Windows. (There are techniques around this like the #ifdef macro. This enables certain code portions only on one platform.)
So a simple hello world program should work on Linux, Mac, Windows or any other platform. You don't need anything special for this.
Note:
Some may mention Cygwin or mingw32. I'll briefly explain what they are:
Cygwin allows you to compile Linux applications using gcc/g++ on a Windows machine.
Mingw32 allows you to compile Windows applications using gcc/g++ on a Windows machine.
Edit:
If you want to setup a system for cross-compilation, then I recommend that you have a look at cmake.
Yes. We are currently compiling a 250 kloc app, running Qt with daily builds. It's working prefectly everyday, although I've to admit it is not distributed outside the company, but only used internal. For official releases, Visual Studio is prefered.
Compiled using mingw standard packages on Debian.
How can a cross compilation setup be achieved to allow compiling Cell Linux programs on a Windows PC using the cygwin toolchain? The cygwin tools provide a GNU compiler to use in building the cross compiler, and associated tools for the build process e.g. rpm, cpio, make, flex, bison and so on.
I am moderately confident this is possible, but unaware of anyone who has actually done this. It has already been done for x86 Linux, but I wish to use Windows, without requiring the use and overhead of a virtual machine running an entire 2nd operating system.
The Cell Linux toolchain is a patched GNU toolchain, with C and C++ compilers for the PPU and SPU processors, and associated binutils. The sources for the Cell Linux SDK for Cell Linux can be found here. The source RPMS here have build scripts for use with the rpmbuild tool on Linux.
The specific question is: how can a set of Cell Linux GNU compilers for the PPU and SPU processors be built, on Windows, using Cygwin.
I've never done it, so I can't give you step by step instructions, but I can give you a general idea.
The instructions you linked will serve as a pretty good outline, but there will be definite changes.
For the host PC, you can install gcc and other build tools from MinGW or cygwin. That will give you the windows native parts of your toolchain.
Then you'll need to download the sources for the cell portions of the toolchain and compile them (with the appropriate options, --target, etc.) using the build environment you just installed.
Then you download and compile the sources for libspe2, and you're done.
But I'll warn you - it sounds easier than it is. Be prepared to spend a lot of time on it.
Since you can already do this on Linux x86, why don't you just install Linux a virtual machine? Also, what might be even easier, is to install Portable Ubuntu for Windows. It runs Linux alongside Windows using coLinux. Although this may not be optimal, it is probably much easier than trying to compile everything on Windows.
the ps2dev toolchain can easily be set up under cygwin
http://ps2dev.org/ps3/Tools/Toolchain
You should be able to build a canadian cross compiler on Linux that runs on windows and creates code for PS3. Have a look at the excellent crosstools from Dan Kegel.
Did you check if the Cell/PS3 devtools for windows/cygwin work for you?
A set of tools compiled to run on Windows via Cygwin can now be found on Sourceforge.
Mike Acton has a long, detailed article on cross-compiling for PS3 Linux on his Cell Performance blog.
It may be a bit out of date, but the bits on setting up the toolchain and various SDKs might prove handy.