I am working with a c++ multi-platform project using visual studio 2010, there is a shared portion of code among all platforms, but there is a big portion that is dedicated to each one, I separate them using #if def, but it turns out that code maintenance become very though and the code is cluttered, in addition to problems like code does not compile with some defines turned on or off.
Is there any plugin or tool for visual studio that helps in developing multi-platform projects, for example hide code related to platform, or compile using different #defines turned on/off, check data types, .. ect.
I would be grateful if any one have a suggestion
I do not know about such a plugin for VS, but since it's basically a Windows-only IDE, I doubt there are any. (But of course I could be wrong)
If you're looking for a good cross-platform build system, I'd look to CMake. It's powerful, easy to pick up and can generate build files for almost any popular IDE/toolchain (Visual Studio Solutions, Eclipse Projects, MinGW Makefiles, GNU Makefiles, etc).
It makes cross-platform development of larger projects a breeze!
You could probably eliminate most of the platform dependent code if you switch to the Qt framework. You can keep to using VS with the Qt add-on and by using the platform abstractions of Qt you can target a number of different platforms with (nearly) identical code base. You get unbeatable platform support and portability:
Windows
Linux (Qt is native to KDE and future releases of Ubuntu)
MacOS
BB10 (Qt is native to BB10 too)
Embedded Linux
Android (coming next month)
iOS (next month too)
Jolla
Tizen
The APIs are also better IMO - less ugly and awkward, more consistent. Also QML (JSON style markup for building applications from C++ components using JS for glue code and value bindings) can significantly boost your productivity (up to 10 times without exaggerating). The Qt toolchain supports different kits (combination of library versions compilers and platforms) and multi-platform cross compilation.
There is no "Tool" more than visual studio itself. Separate the code to different projects; Project for common code and project for each platform.
Don't forget to:
1. Add reference to common project in all platform-dependent projects (so common project is compiled before platform project).
2. Add common project base to the common include directories of each target project.
Related
Some of you might already know that Microsoft is trying to kill desktop development in favor of Metro style apps. The express editions of the new Visual Studio 11 will only support writing Metro style apps. They also won't give you the new compilers as part of the new Windows SDK. The only way to get the compilers is to buy Visual Studio Professional or higher.
Now it's time to find an alternative (alternative compilers for the Windows platform). Any suggestions?
Some links that are related to this issue:
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2645679-visual-studio-11-express-on-windows-7-and-the-abil
http://blogs.msdn.com/b/visualstudio/archive/2012/05/18/a-look-ahead-at-the-visual-studio-11-product-lineup-and-platform-support.aspx
http://www.microsoft.com/visualstudio/11/en-us/products/express
Gcc/G++ of course. In my opinion it is superior to VC++. In addition, you can use Eclipse CDT as IDE, it is quite usable at the moment (compared to older versions). I work like that on Windows. In addition, you can also work on Linux or MacOS without having to switch to another tool.
1) The Metro and WinRT features are accessible from C++/CX which in turn is built on top of COM, so according to this detailed discussion (SO question on WinRT and C) you can use the latest "Microsoft-only" features with any decent C compiler. Of couse this will require some code generation or just a lot of typing to get the access to basic facilities. I believe there would be a transition period and then the open-source community comes up with some automated solution to consume the WinRT APIs.
2) A quick list of available options right now.
Dev tools: MinGW or Cygwin (GCC toolchain + unix-like tools), Clang maybe, OpenWatcom as a thing from the past
GUI Libraries: FLTK, Qt, wxWidgets, Fox GUI toolkit, librocket (if you are into the OpenGL world)
IDEs: Code::Blocks, Eclipse+CDT, QtCreator
3) There's also a non-C++ way:
The FreePascal+Lazarus to allow Delphi-like RAD
Mono/SharpDevelop
Both options can use C++ code with some bindings.
4) Conclusions
These are the alternatives which give similar results but not always the similar level of comfort.
Yet another possibility would be Qt Creator, which comes with a full toolset targeting Windows (as well as MacOS, Linux, and Symbian). It is definitely somewhat different from VS, so it takes some getting used to, but overall I'd rate it as pretty decent. Qt (the library) generates somewhat mixed feelings -- some dislike its oddities (E.g., MOC), but quite a few consider it the best designed GUI toolkit available.
Don't forget the Netbeans GUI which is also available for windoze. It works great, just install mingw and choose this mingw/bin directory for the compiler tools and mysys/bin/make.exe as the make program
to download
https://netbeans.org/downloads/index.html
they have this plugin for vc++
http://plugins.netbeans.org/plugin/42519/vcc4n-visual-c-compiler-for-netbeans
some install info
https://netbeans.org/community/magazine/html/03/c++/
Another IDE that I havent used but looks good is
http://www.codeblocks.org/
I have a C++ eclipse project that I would like to easily compile In Windows and OSX.
The project is currently using an automatically generated makefile.
The libraries that I need vary depending on the platform.
In osx I'm using the CoreMidi, CoreAudio, and CoreFoundation frameworks.
In Windows I'm using the winmm.lib and multithreaded libraries.
What's the simplest way to link different libraries/frameworks depending on the current platform?
I'm currently using the gcc toolchain on OSX. Should I start using the cross compile toolchain?
Should I have two projects. One for working in windows, and one for osx, checking them both in to version control?
Should I write a custom makefile instead of using the automatically generated option that has different g++ arguments depending on the platform?
I personally had the same goal for a project and came to the conclusion the Qt framework was the best thing for me. It handles multiple languages, unicode strings, XML, network communications, native looking user interfaces, console applications: it can do an AWFUL lot.
However, as Paul pointed out, you really have to plan it from the start.
Qt does a good job of abstracting the platform away (in a module called QtCore) allowing you to write vanilla C++ code, or you can chose to include some Qt C++ language extensions which a Qt helper application called the moc (meta object compiler) creates vanilla C++ from, which can then be compiled by most common C++ compilers.
It also has a nifty cross-platform makefile generator called qmake which works on project files to create normal make files for the platform its running on.
Off the top of my head at least Windows XP & 7, OSX 10.4, 10.5, 10.6 are supported currently. But note that OSX Lion is (as of writing) not officially supported but I suspect it will be in the next release.
Based on your description, I am not sure you can easily make it cross-platform. Even without using third-party library, you have to provide separate code for osx and windows. Most of time, they design the system as cross-platform first. It's really hard to make an existing project on single-platform to cross-one. If you have the cross-platform requirement, you'd better design in that way first and rewrite from scratch.
Even though Eclipse can run fine on both OS X and Windows, it is not designed to be used in this way.
The best way to do it is to use separate IDE projects for each platform. This this is the easiest way to have unique compilation settings for multiple platforms.
Yes, you can use two eclipse projects. Alternatively, it's not unusual to have a X-Code project for OSX, and a Visual Studio Project for MS Windows.
I have a few projects where most of the code is written in platform-agnostic C++, with a relatively thin platform abstraction layer for each supported platform. For most platforms this abstraction layer is also written in C++, but for iOS and OSX it also contains some Objective-C code. For this reason, I have Xcode projects for the iOS / OSX builds, and Visual Studio projects for Windows, but I'm a bit tired of having to maintain multiple project files.
It would be so nice to only have one cross-platform IDE, one project file for that IDE, then just add all source files to that, and make some of them included in the build only in certain configurations. But for that I'd need an IDE that runs on multiple platforms (Windows, OSX, preferably linux too), and supports not only C++, but Objective-C source files as well. Is there such a thing?
You can try QtCreator. It's a cross-platform IDE developed for Qt but it supports Objective-c too:
http://qt-project.org/downloads
I'm working on a cross-platform C/C++ code base that has Visual C++ (super majority) & XCode developers. It also needs to compile on Linux, because that's where it's deployed. We are currently using a complicated Unix makefile that's called from Visual C++, XCode, & Unix command line.
However, the makefile project causes several productivity losses for Visual C++ developers:
Slower build times
Intellisense & text search don't work well for files not directly referenced in project
No .h dependency generation (not clear how to do on Windows)
Adding a native Visual C++ project has the following downsides:
lots of work to manage all those separate platform configuration as mentioned here Maybe VC++ 2010's hierarchical property sheets will help.
more work due to syncing makefile with native project
Currently, I'm considering to add a native project for Windows developers. Can anyone offer their experience on what's best or suggest how those problems with either approach can be reduced.
I have considered CMake and personally would use it, but it's going to be hard to convince other people to learn cmake & syncing it with the native projects would be an issue.
I have considered CMake and personally would use it, but it's going to be hard to convince other people to learn cmake & syncing it with the native projects would be an issue.
The nice thing about CMake is that it builds ALL of the configurations for you. You would setup a single CMake project, and then use it to generate VS solutions, XCode projects, and unix makefiles for you.
It's a huge improvement - everybody gets to work in their "native" environment, whether they're on Windows, Mac, or Unix.
I've handled this by writing my own converter that would synch scripts for various embedded development environments. If something like the above answer of using CMake does all that for you, then that would be the way to go. But if its too complex, rolling your own custom tool is not that hard. Just has to synch both ways.
Also, if you don't have it. Visual Assist for visual studio is awesome :)
I am not a fan of makefile generators, cmake, qmake and the like.
I am a fan of make. We have a single makefile (well, several actually but they include each other and there is no recursive make involved) which knows all of the project dependencies on all platforms (windows, wince, linux, mac, ...). This gives:
Makefile is really no more than a list of sources (include dependencies are auto-generated during the build)
Same build command on each platform, apart from specifying the tool chain
Build uses all my CPUs
Very short time-to-do-nothing
Developers can use whatever IDE they fancy
vim, emacs, qtcreator, eclipse, XCode all in use
I often use VC++ when on Windows (for the debugger)
Scriptable. Great way to automate your tests
Nice.
I'm involved in C++ project targeted for Windows and Linux (RHEL) platforms. Till now the development was purely done on Visual Studio 2008. For Linux compilation we used 3rd party Visual Studio plugin, which read VS solution/perojects files and remotely compiled on Linux machine.
Recently the decision was to abandon the 3rd party plugin.
Now my big concern is a build system. I was looking around for cross platform build tools. This way I don't need to maintain two set of build files (e.g. vcproj/solution for Windows and make files for Linux).
I found the following candidates:
a. Scons
b. cmake
What do you think about the tools for cross-platfrom development?
Yet another point that bothers me is that Visual Studio (+ Visual Assist) will loose a lot functionality without vcproj files - how you handle the issue with the tools?
Thanks
Dima
PS 1: Something that I like about Scons is that it
(a) uses python and hence it's flexible, while cmake uses propriety language (I understand that it's not a winner feature for a build-system) (b) self contained (no need to generate makefiles on Linux as with cmake).
So why not Scons? Why in your projects the decision was to use cmake?
CMake will allow you to still use Visual Studio solutions and project files. Cmake doesn't build the source code itself, rather it generated build-files for you. For Linux this can be Code::Blocks, KDevelop or plain makefiles or still other more esoteric choices . For Windows it can be among others Visual Studio project files and still others for MacOS.
So Visual Studio solutions and projects are created from your CMakeLists.txt. This works for big projects just fine. E.g. current Ogre3d uses CMake for all platforms (Windows, Linux, MacOS and IPhone) and it works really well.
I don't know much about scons in that regard though, I only used to build one library and only in Linux. So I can't compare these two on fair ground. But for our multi-platform projects CMake is strong enough.
I haven't used Scons before, so can't say how that works, but CMake works pretty well.
It works by producing the build files needed for the platform you're targeting.
When used to target VC++, it produces solution and project files so from VS, it appears as if they were native VS projects. The only difference is, of course, that if you edit the project or solution directly through VS, the changes will be erased the next time you run CMake, as it overwrites your project/solution files.
So any changes have to be made to the CMake files instead.
We have a big number of core libraries and applications based on those libraries. We maintain a Makefile based build system on Linux and on Windows using the Visual Studio solution for each project or library.
We find it works well for our needs, each library or app is developed either on linux or windows with cross compilation in mind (e.g. don't use platform specific api's). We use boost for stuff like file paths, threads and so on. In specific cases we use templates/#defines to select platform specific solution (for example events). When is ready we move to the other system (linux or windows), recompile, fix warnings/errors and test.
Instead of spending time figuring out tools that can cross compile on both platforms we use system that is best for each platform and spend time fixing specific issues and making the software better.
We have GUI apps only on Windows atm. so there's no GUI to cross compile. Most of our development that is shared between Windows and Linux is server side networking (sockets, TCP/IP, UDP ...) and then client side tools on Linux and GUI apps on Windows.
Using with perforce for source code version management we find in quite many cases that the Linux Makefile system is much more flexible for what we need then Windows VS. Especially for using multiple workspaces (views of source code versions) where we need to point to common directories and so on. On Linux this can be done automatically running a script to update environment variables, on Visual Studio referencing environment variables is very inflexible because it's hard to update automatically between views/branches.
Re sync question:
I assume you are asking how to make sure that the two build systems get synchronized between linux and windows. We are actually using Hudson on Linux and CruiseControl on Windows (we had windows first with cruise control, when I went to setup linux version I figured Hudson is better so now we have mixed environment). Our systems are running all the time. When something is updated it is tested and released (either windows or linux version) so you would know right away if it does not work. During testing we make sure all the latest features are there and fully functional. I guess that's it, no dark magic involved.
Oh you mean build scripts ... Each application has it's own solution, in solution you setup up dependencies. On Linux side I have a makefile for each project and a build script in project directory that takes care of all dependencies, this mostly means build core libraries and couple of specific frameworks required for given app. As you can see this is different for each platform, it is easy to add line to build script that changes to directory and makes required project.
It helps to have projects setup in consistent way.
On Windows you open project and add dependency project. Again no magic involved. I see this kind of tasks as development related, for example you added new functionality to a project and have to link in the frameworks and headers. So from my point of view there is no reason to automate these - as they are part of what developers do when they implement features.
Another options is premake. It's like cmake in that it generates solutions from definition files. It's open source and the latest version is very highly customizable using Lua scripting. We were able to add custom platform support without too much trouble. For your situation it has support for both Visual Studio and GNU makefiles standard.
See Premake 4.0 Homepage
CruiseControl is a good choice for continuous integration. We have it running on Linux using Mono with success.
Here is an article about the decision made by KDE developers to choose CMake over SCons. However I've to point that this article is almost three years old, so scons should have improved.
Here is comparison of SCons with other building tools.
Had to do this a lot in the past. What we did is use gnu make for virtually everything including windows at times.
You can use the project files under windows if you prefer and use gnu make for Linux.
There isn't really a nice way to write cross platform makefiles because the target file will
be different among other things (and pathname issues, \ vs / etc). In general, you'll probably be tweaking the code across the various platforms to take subtle differences into account, so a tweak to a make file and checking on the other platforms would have to happen
anyway.
Many OS projects maintain Makefiles for different platforms such as zlib where they are named like Makefile.win, Makefile.linux etc. You could follow their lead.