How should I setup a C++ project on github so that it is portable?

Question

I would like to start a C++ project on GitHub such that I will be able to clone/build on different operating systems (for example, OSX and unix). There will be lots of dependencies that need to be installed (for example curl, libxml2, etc), and much as possible I'd like to avoid having the user need to manually install the deps on the system. Is it possible to do this?

Answer 1

It depends on how much you want to bite off.

The short answer is let CMake do the work. It will generate projects for whatever platform and they should be usable. You don't need to distribute binaries for this, assuming they are readily available to you (and to them, by extension).

Here is an example that sets up sqlite, boost, and eigen that I used for one of my projects.

cmake_minimum_required(VERSION 2.8)
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/Modules)

# boost
find_package(Boost 1.42.0 REQUIRED )
include_directories(${Boost_INCLUDE_DIRS})
link_directories(${Boost_LIBRARY_DIRS})

find_package(Eigen REQUIRED)
include_directories(${EIGEN_INCLUDE_DIRS})

find_package(Sqlite3 REQUIRED)
include_directories(${SQLITE3_INCLUDE_DIR})

set(CMAKE_CXX_FLAGS "-std=c++0x")

include_directories(.)

link_libraries(
    ${Boost_LIBRARIES}
    ${SQLITE3_LIBRARIES}
)

add_executable(igd_sqlite
    main.cpp
)

You'd take this and generate visual studio projects, makefiles, etc. Then build the project as you normally would.

CMake supports lots of libraries out of the box, though sometimes you do have to google for less popular ones and add them to your project.

I use it for my day-to-day work, even when I don't need cross platform.

When I do actually want to distribute binaries, I usually setup an external folder with the binary files.

Here is an example:

https://github.com/tomisarobot/curl_race

This works great if you don't have a lot of external dependencies and if they aren't huge. When that isn't the case, then I'd recommend putting each plattform in different repositories. Your source should be in its own too. You can use subprojects if you want, though that isn't strictly necessary. External deps dont change that often, so its not always worth the overhead. Usually I just write a bash script to document where to get everything. This script is usually necessary for a distribution build anyway.

Things like the maven-nar-plugin exist, though I am unaware of its maturity. If you're just creating all the binaries to distribute with your source anyway, then maybe it isn't that attractive. I don't see a lot of talk about it, so I assume adoption is low. Having seen what maven does for Java, it should be more popular.

Answer 2

Few thoughts

1) Tools

• When possible, include the tool sources in the repository so that one can build them as a first-time-only step

• When not possible, clearly specify what minimum version of what tool is required so that the user can install them herself

  • Possibly check if the dependency requirements are satisfied by running a script

2) Language

Compile with strict language compliance. For example

   g++ -std=c++11 -pedantic