Question

I have recently started a new C++ project and I intend to make it cross-platform in time. I haven’t had much experience with C++ projects before so the first thing that bothers me is that default Visual Studio file layout setup. I tried reading-up the Net on this subject but the info just seems rare and conflicting, so I started by doing something simple like this:

build
  vc2010  // Visual C++ solution/project files
lib 
  include // Header files for third-party libs
  // All library binaries here (like .lib, .dll or .so)
src
  // My own code (including headers)
temp
  // I use this as intermediate file output directory (for Visual C++)

Then Visual C++ project is configured to output final .exe in a root project directory (debug/release builds) so I can put there my own specific data as well (like data/ dir). Please note, I intend to manage my project under source version control repository (excluding some types like .exe) and I am not writing a library here. So my questions are:

Are there any de-facto standards for structuring your projects? Or are they platform and user specific?

How do you handle library dependencies? Do you just put pre-compiled binaries (like in my setup) or use full library source code and setup your project build process to include them in the process. Is it a good idea to put binary files under version control (like .lib/.dll in this case)?

Answer 1

Just keep in mind what happens when you switch to a different build system on another platform.

It won’t know what to do with solution/project files, they’re specific to Visual Studio. So it doesn’t really matter how you structure that. You’ll be re-doing it anyway.

Likewise with the temp directory, intermediate files are specific to the build system, they don’t necessarily have to be off in their own tree. You’ll probably want to stick with the default for each platform, whatever that is.

With third-party dependencies, you might find they’re already installed (or can be installed) on the system you’re porting to, in which case you might be happy to use the installed version, or you might depend on a very specific version. Either way, pre-compiled binaries are useless on another system.

So, if you want to take your third-party dependencies with you, and compile them wherever you go, then you need to treat them like your own sources, but in another root. Version-control the source but not the binaries. If you’re going to use whatever’s available pre-compiled for the target platform, you’ll probably find you have to do things slightly differently on different platforms but that basically you’ll either stick them somewhere, or find them somewhere already installed, and put that “somewhere” in your include path (for header files) and your linker path (for binaries).

You might want to version-control the binaries to be on the safe side, or you could just make a note what version you’re using, and use backup rather than version control as your insurance against them being unavailable to download in future.

If you want to design for portability from the start, it might be a good idea to set things up for two different systems at the same time. You can do this without leaving Windows – for instance try installing Code::Blocks and build with MinGW as well as what you’re already doing with Visual Studio.

Also beware that a lot of the libraries you’d naturally use on Windows, simply aren’t available on other platforms. The build system will be the least of your worries if you’ve written a GUI app based on the Windows APIs, then you want to port it to OSX.