C++ Build Process

Question

I am currently working on an opensource C++ project. I don't have much experience in C++ as my daily job mainly involves with Java. I am now planning to release my C++ project and I would like to know how should I should I arrange the packaging of my project. E.g, in Java, all the class files are packaged into jar file. So what is the equivalent approach in C++? Is there any good practise for organizing the source code/binary? My target platform is Linux by the way.

Another question is I am currently using Eclipse CDT plugin for development and building. So is there anyway that I can extract build script from Eclipse project and use it as generic build script? Is there any good reference regarding C++ build/packaging? Thanks in advance.

---

Edited

To clarify a bit more, I think the release of my project can be considered as an application. It's a command line tool for software configuration management.

Answer 1

I am currently working on an opensource C++ project.

That simplifies many things. You should supply the build scripts for you project and support them for different use cases (learn about Makefiles, there are similar concepts like "target").

I don't have much experience in C++ as my daily job mainly involves with Java.

Most of the things you're used to have (and ask for right now) in Java are invented because they lack in C/C++. Learn at least something about dynamic(shared)/static libraries (.so and .a files to be simple).

I am now planning to release my C++ project and I would like to know how should I should I arrange the packaging of my project.

The "packaging of a C++ project" is something informal. You may supply the sources, build scripts and some project-files for the well-known IDEs.

EDIT: you've specified that you're building the command-line application. I believe all you need is to start from a simple Makfile for that application. The reference Makefile can be automatically generated by Eclipse. If you are planning to deploy your application as a stand-alone software, then you have to earn about packaging (rpm, deb, tgz).

E.g, in Java, all the class files are packaged into jar file.

There are no such thing as a C++ "package" compatible accross compilers (even the "modules" were rejected in the latest C++11 standard) because there is no binary standard to encode C++ classes (ABI). On linux you're most likely going to use GCC (or Intel's compiler, or LLVM's CLang, or custom build of OpenWatcom or...), but the version of standard library you are linking to makes the release of binary builds close to useless. That is the reason for redistibuting source code.

So what is the equivalent approach in C++?

No clear answer here.

Is there any good practise for organizing the source code/binary?

Look at the large-scale projects, see the way they organize their builds. The term "build engineer" as an occupation emphasizes the difficulties of large-scale projects compilation/linking.

My target platform is Linux by the way.

This is also something of an incomplete description. "Linux" is a blurry term. You should speak about the Linux distribution, compiler toolchain and package manager. E.g., Ubuntu 12, amd64, GCC 4.6 toolchain, APT package manager.

There are different "linuxes" built around the same kernel source. There are different compilers. There are at least three major package managers to consider: Debian/Ubuntu(deb,apt), Red Hat(rpm), Slackware(tgz).

Another question is I am currently using Eclipse CDT plugin for development and building. So is there anyway that I can extract build script from Eclipse project

There's a sort of "meta-technique": you write a "description" of your project and then a tool generates the project-file and build scripts for your sources. Have a look at CMake. Since you're on "linux", try looking at the somewhat standard way of autotools (autoconf).

Is there any good reference regarding C++ build/packaging?

You should start by building your application and then move on to the deployment issues. C/C++ is a hard-to-learn legacy with a lot of subtleties which are avoided in Java.