6

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:

  1. 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?
  2. 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?
  3. 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 :)

Mithadis
  • 113
  • 2
  • 8
  • 2
    Definitely use a tool like cmake. I would advice to compile first with gcc and test after with visual (with visual first, you may discover pages of warning when compiling with gcc) but that's my opinion – rocambille Aug 05 '16 at 13:06

2 Answers2

3

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!

  1. 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.

  2. 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.
Community
  • 1
  • 1
Sompom
  • 223
  • 2
  • 13
  • Thanks, that's very useful. Just one question - what do you mean by "overkill solution" and "licensing requirements" ? Does using QT/qmake imply some kind of restrictions? – Mithadis Aug 08 '16 at 07:41
  • Qt is overkill because it is a fairly large dependency, which may or may not be a problem depending on what you need. Qt is licenced under the LGPL with some parts GPL, or you can pay for a commercial license. LGPL is not a deal-breaker for most situations, but be sure you research it carefully to know what you're getting into. – Sompom Aug 08 '16 at 13:52
  • @Mithadis - Sorry, I forgot to tag you yesterday. I want to make sure you've seem my response. – Sompom Aug 09 '16 at 13:45
1

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.

marangisto
  • 260
  • 2
  • 8