views:

151

answers:

3

I am starting a c++ project which I would like to compile equally well in Eclipse (Linux) and vs2010 from the same repository and could use some help getting started. While many of the aspects can individually be Google'd, I was hoping for advice on how to approach the problem on a whole.

For example, where to keep the library sources, how to structure the make file, and how to integrate googletest (finding a novice tutorial on googletest alone is hard). A link to a tutorial that addresses these aspects would be great, or a series of tutorials that together could help.

My background is in C# and I'm trying to maintain the "cleanness" and organization of my VS projects.

+3  A: 

One thing that I could suggest if you're going strongly cross-platform and you want everything to be as "clean" as possible: Centralize your build system with a modern cross-platform build tool like Scons. It's written in Python, it's quite concise and powerful, and it works everywhere.

Or, if you're a fan of Eclipse, just install Eclipse on both Windows and GNU/Linux. As I mentioned above, it's cross-platform, and you can get it working for compilers on all sorts of different systems.

Reinderien
It looks promising, but how difficult will it be to implement? I just wrapped myself around make
ccook
In my humble opinion, make syntax is terribly hacky. If you read about its history, it was never really intended to be a public, large-scale build solution. It's difficult to scale, difficult to maintain and has pretty poor human parsibility. Just look at the number of tools that pile obfuscation on top of obfuscation (automake and their kin). On the other hand, Scons is simply Python, and it's well-documented with plenty of examples.
Reinderien
@ccook: SCons is much more automated, and since you have the full power of python, you can use `glob.glob` and `os.listdir` to get the list of files in a directory, thus avoiding to maintain the list of files...
Matthieu M.
@Matthieu M. Would you still put it as a plus if I did not know python?
ccook
Matthieu M.
I have only heard good things about python. http://xkcd.com/353/
ccook
+4  A: 

You'll want to look at cmake.

Hitesh
+6  A: 

I have done cross platform projects that used the "native" build systems on both platforms (vsproj files on windows and makefiles on linux), but it was definitely a pain to maintain both project files. So, yes, I would agree with the other suggestions that you should try to start with a solid cross platform build utility. CMake or possibly Boost build seem like decent options - likely there are many others.

When it comes to 3rd party libraries, you'll want to stick to stuff that is solidly tested cross platform. Boost is the best general purpose library for c++ (yes, you see it mentioned here in just about every c++ thread...but that's because it really is a nice collection of useful stuff). As for XML, HTTP, image libs, UI - there are all good cross platform options - just look around or ask here if you have specific requirements. Whatever you do, don't use some library from CodeProject or other MS oriented site that has only been tested with Visual Studio 6 - that will just lead to misery. Most of the GNU libs build on windows these days, so you should be reasonably safe with that stuff.

Although it will be tempting, try to minimize the platform#ifdefs in your code - prefer instead to abstract any platform specific stuff in a library wherever possible.

Good luck!

Mike Ellery
wish I could make more than one upvote
Tim
Regarding `#ifdef` s vs. separate libraries - it is not unreasonable to put common code in a base class in one library, then extend that class to separate platform-specific child classes that vary platform-specific behaviour using polymorphism. Then the only `#ifdef`s needed are to govern which child class is used.
Reinderien
Regarding the ifdef/separate libraries, you can also have a common header file, then split source files with some of the source in a shared cpp and some of the source in platform specific files that are only build on the appropriate system.
Paul Whitehurst
The libraries are open source; should I just compile them locally as part of the build process and leave out the binaries from the repository? Thank you
ccook
I found a nice Boost build intro: http://www.highscore.de/cpp/boostbuild/ Looks really good
ccook
@ccook - yes, I would recommend you build your third party libs on a reliable shared file system (samba running on linux works just fine for this, but any modern network file system will be fine..). Keeping all those bins and third party headers out of your repository is best (although I can't tell you how many places I've encountered exactly the opposite). Also, you can use environment variables to specify the root location of your 3rd party libs and then just reference that ENV setting in your make/project files - this helps if devs like to mount the shared location differently.
Mike Ellery
@ccook - one more note on 3rd party libs: If you organize them by project, be sure to put each version of the libs in it's own directory named by version number - e.g. "3rd_party/boost/1.44.0/<FULL FILESET HERE>". This greatly simplifies upgrading to new library versions as needed as it lets you keep multiple versions around during a transition period. Once you are confident that you have fully upgraded all projects, you can delete old library versions. That system has worked well for me - YMMV.
Mike Ellery
@Mike Thanks! I'm using Mercurial, but I will do as you suggest by including the version number in the third party libs
ccook