Some of basic requirements are:
Basic build scripts requirements like pulling from scm, copying, compiling :)
Compatibility on Windows, Unix (Solaris, HPUX, AIX) and Linux.
I have heard of several good options like scons, ant etc but would like to know what is your favorite choice?
Currently I have 36 kornshell scripts which i need to port as kornshell is not supported properly even in SubSystem for UNIX in windows.
My vote goes for cmake. It is important for me that it is a meta buildsystem.
CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice.
Linux users work with eclipse, windows user with visual studio.
I also considered scons with the full power of python behind it but as stated in the scons wiki:
To sum up, my very subjective opinion is that scons is a better idea, but CMake has a stronger implementation
Related
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'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 wanted to create a cross-platform 2D game engine, and I would like to
know how to create a cross-platform project with Makefile, so I can compile it to the platforms I choose with custom rule for any platform.
I'm working on the windows enviroment with Visual C++ Express 2008, so it would be nice
if I can use Visual C++ Express as the IDE.
My platforms are YET the Nintendo DS and the PC.
Please instruct me what to do.
Thanks in advance, Tamir.
Don't use make, use a cross-platform tool like cmake, it will take care of the platform-specific generation for you. Like on Windows, it will generate the project files to use Visual Studio; on Linux, it will generate the GNU make files for you. You can set it up to find the right versions of the right libraries and everything. Cmake is great.
CMake is not a compiler (neither is make) - it is a cross-platform build automation system. It allows you to develop on any platform and it defaults to assuming you're developing for the platform you're running. You can specify parameters if you want to do other things. However, most of the "cross-platform" stuff is still left to your code. I would also recommend a library that has been tested on many platforms, like Boost. Using Boost can help keep all your code working smoothly on any system and there is basically no overhead to using it.
I know you can use Makefiles to do #defines, which is, in turn, a common trick for swapping out chunks of code. There are also ways to detect the platform, although that's mostly for Mac/Windows/Linux differences.
Also, Travis is probably right; having your makefiles themselves be cross-platform is really excellent, since it's easier to then setup build servers and things.
I am starting to write a moderately sized project in C++ requiring a fairly large amount of files and dependencies on other projects.
Do you think manually maintaining a Makefile for this project is the best approach?
Are there other better alternatives for C++ that make build management and dependency management of files really easy to handle?
Also, what IDE is good for C++ development on Linux? I am comfortable with Vim, but do you think there are good IDEs for C++ (like Eclipse for Java) that provide code-completion etc?
Thanks!
Ajay
Others have already recommended using CMake. To my mind you should manage your project with CMake then decide on your favourite IDE.
CMake allows you to describe the project to be built, instead of how to build it. For example: I want to create a shared library called foo with source files a.cpp, b.cpp and c.h and it requires these link dependencies. Then on unix you get libfoo.so and on windows you get foo.dll and foo.lib. All common project settings can be abstracted up to higher levels in the build tree, this keeps most files very simple. More complicated requirments can be refactored into macros.
Once your project is described like this CMake will generate makefiles and/or IDE projects. This means each developer can choose their own IDE, as well as allowing you to mandate an IDE if appropriate.
My company use CMake to build the c++ in our product on windows and solaris. It contains 600 projects and 1.5 million lines of source code. We originally chose it as a cross platform build utility when porting to solaris, however for a large project like ours it is much easier to manage the build with CMake than with Visual Studio project files. I would recommend it as a build utility for any c++ project of any size
We use the eclipse cdt on solaris and are very happy with it. Most of our development is with visual studio on windows. cmake also works well with other ides I use it with KDeveloper4 on linux at home without a hitch.
KDevelop4 (from subversion or rc1 from their site) + CMake makes life so much easier, automake should just die.
If you want a cross-platform solution, netbeans + the c++ plugin are pretty decent, not as good as kdevelop4 though.
I like CMake a lot for the whole building process (but I have almost no experience with scons or Jam).
I use vim or qtcreator. Qtcreator is still in developpment, but very promising I think.
I suggest you Code::Blocks. I use it on Debian and works gracefully.
http://www.codeblocks.org/
Edit: Added another link
http://wiki.codeblocks.org/index.php?title=The_build_process_of_Code::Blocks
Eclipse does C++ as well - through eclipse CDT - not as comprehensive as Java but pretty good.
Manually maintaining Makefiles in larger Projects becomes quite painful. If you start using automake/autoconf, you will - after a while of learning all the facets - appreciate the powerful possibilities these tools can offer.
And as IDE simply use Emacs. It's quick, powerful and supports Code completion etc.
There's also Code::Blocks as an IDE with its own building system. But I would encourage you to try out other build tools (CMake, Boost.Build, SCons) if you want to be able to build your software "anywhere" without having a fancy schmancy IDE installed. ;-)
I found Emacs + Scons works pretty well for me.
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.