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.
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.
Related
I am a java developer for last four years . I am planning to develop an c++ application which uses the library like boost etc.
In java we can add the libraries in class path and export as single jar and distribute it .
I am not sure how to do this in c++ and more over i use ant for build too in java.
Do we have any build too like ant for c++.
What are the things we need to consider while developing an c++ application in terms for supporting different operating systems and some general things.
Do c++ have some thing like maven in java?
There is no such thing like Maven for C++. Dependency Management is usually done either by your operating system (Unix package manager like apt-get or yum) or by Hand (Windows ;)).
For multi platform environments I would recommend CMake as it can generate Project files for Visual Studio, Eclipse, XCode, Unix Makefiles etc. CMake can provide you with a lot of tool functions like find_package (XXXXX) which make life a lot easier.
IMHO the best way to learn it is to read documentation of your compiler, your build tool (e.g. CMake) and some sample code. Some keywords are 'static library', 'dynamic library' (like DLLs, 'linking'), include path. Start with something simple like a small program which uses Boost and maybe the CURL library and try to build it on multiple platforms.
Seems most open source projects in C/C++ only provide the source code,i.e. nginx
Is this a convention that anyone interested in joining the developing team should figure out the .sln/.project files himself to qualify??
most open source projects are coming from the linux side of computing. thus, they are mainly using unix style build tools, as well as open source compilers.
the main build tool is make, which uses a makefile to know how to build a project. on Windows, the main open source compiler is MinGW which is a win32 port of gcc. the use of those tools allows to keep a maximum of common things between unix and windows.
note that .sln files are specific to microsoft compilers which are not free to use (and are rather costly), they are not portable and so are not suitable for multi-platform programming.
Some projects use CMake, which can generate project files for Your Favourite Build System, but as mentioned above, you don't need to use .sln and pro files, even if a project is built with the MSVC compiler, MinGW + makefiles, or scons, or CMake, or any other number of scripty methods to invoke the right commands to compile the program will work just fine.
Don't confuse the IDE with the compiler!
No, most opensource project do not use MSVC solutions as they not portable and very weak in terms of features.
In most cases they use what is called "build-system" like autotools, CMake or SCons.
These build systems include information about:
source code and how to build it
various system checks that should be done (like find various 3rd part libraries)
How to build and run unit-tests
How to install application
They also allow important tasks like cross compilation and packaging for deploy.
These task done via specific build system scripting language that allow you big flexibility.
So, these build systems generally much more powerful then typical "project files" and they
generally work with multiple compilers on different platforms and operating systems.
Some of build systems (like CMake) allow as one of the options to generate MSVC solutions as well as one of optional ways to build application.
I currently maintain a few boxes that house a loosely related cornucopia of coding projects, databases and repositories (ranging from a homebrew *nix distro to my class notes), maintained by myself and a few equally pasty-skinned nerdy friends (all of said cornucopia is stored in SVN).
The vast majority of our code is in C/C++/assembly (a few utilities are in python/perl/php, we're not big java fans), compiled in gcc. Our build toolchain typically consists of a hodgepodge of make, bash, grep, sed and awk. Recent discovery of a Makefile nearly as long as the program it builds (as well as everyone's general anxiety with my cryptic sed and awking) has motivated me to seek a less painful build system.
Currently, the strongest candidate I've come across is Boost Build/Bjam as a replacement for GNU make and python as a replacement for our build-related bash scripts. Are there any other C/C++/asm build systems out there worth looking into? I've browsed through a number of make alternatives, but I haven't found any that are developed by names I know aside from Boost's.
(I should note that an ability to easily extract information from svn commandline tools such as svnversion is important, as well as enough flexibility to configure for builds of asm projects as easily as c/c++ projects)
We've started using CMake here at work recently. I've been pretty happy with it so far.
scons or cmake.
Both "cross platform" - enable compiling on Windows and Linux.
Cmake now very popular (for example boost uses it). It creates native build files for each platform - Makefiles (for Linux), VC++ projects (for Visual Studio) from custom files (CMakeList.txt). In can also create Eclipse projects, KDevelop projects etc. Since it creates native build files, you can continue using all features you're used for. For example, ccache/colorgcc/distcc for Makefiles or Visual Assist X for Visual Studio.
We use it our project and are happy with it - automatic dependencies, easy syntax, robust builds.
Scons is python bases system, which perform the builds by itself. It's IMHO less popular, and still slow for large project. But for msmall to medium project maybe good alternative.
You could use python-based build system, too -- http://code.google.com/p/waf/
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I want to build a shared library. GNU/Linux is the development and target platform. C is the implementation language.
I can't decide how I want to setup the build system and keep flitting around three options each of which have lots of reasons to dislike:
hand crafted Makefiles - I've worked this way almost exclusively in the past
GNU Autotools - I used autotools earlier this year to build a shared C library, but have forgotten how I did it and where all the many hundreds of tutorials were I used for pickings.
waf - supposedly simple but not so easy I've got it working this afternoon.
I can't decide which to go for. I'll settle on one, start working then come across a problem and decide the other system is better. I'm stuck stuck stuck. Can someone shed some light on this please which might help me settle the matter?
Here's some links (and quotes from the site) to the tools I've noticed over the years:
PreMake: You are the manager of a software project. Your users are asking you for a Visual Studio workspace file, but you don't have Visual Studio! Or perhaps you are a Windows developer struggling to keep Makefiles in sync for a Linux port. It's a common problem for open source projects: restrict your users to a single build tool -- driving away potential contributors -- or manually maintain two, three, or more sets of build scripts. Enter Premake.
CMake: Welcome to CMake, the cross-platform, open-source build system. CMake is a family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice.
buildconf: It started as just a little build preparation script... and over the years has grown to be quite a useful utility saving me time and effort with support requests and cross-platform compilation. It's the same sort of script often commonly found among projects that use the GNU Build System -- also known as just the GNU Autotools or for each tool individually as Autoconf, Automake, and Libtool. These projects frequently have a custom helper script written that prepares the build system for their project's developers, usually running various tools like libtoolize, autoconf, or autoreconf. This script is often named either buildconf or autogen.sh but the intent is the same: to prepare your build system for compilation
BSDBuild: BSDBuild (formerly csoft-mk) is a simple, self-contained and portable build system derived from the traditional 4.4BSD share/mk files. BSDBuild allows BSD-style makefiles, but without BSD make extensions (it uses standard Bourne script fragments instead), so the build system is portable to most operating systems and make flavors.
iCompile: iCompile the zero-configuration build system
OMake: (OCaml) OMake is a build system designed for scalability and portability.
BakeFile: Bakefile is cross-platform, cross-compiler native makefiles generator. It takes compiler-independent description of build tasks as input and generates native makefile (autoconf's Makefile.in, Visual C++ project, bcc makefile etc.).
SCons is an Open Source software construction tool—that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software.
Make project: 'Make project' is a bash script that makes project skeletons. It automatizes the task of start a new project with the information provided from the command line. The package created by default is a 'hello world' project of the selected skeleton that uses the autotools to be managed.
Unmaintained or dead projects (07-2012)
cppmake: Cppmake is a front-end to make that builds C++ programs with less effort and more accuracy than writing makefiles manually.
spray: Spray is a build tool helping you in configuring, building and installing your project It is similar in purpose to the autotools or CMake but created following the spirit of SCons and waf using the Python programming language.
Since the purpose of your build system is installing the library into target systems, you should use one of the generic tools everyone who installs the software is familiar with.
So the main purpose of the build system is flexible configuration capabilities.
What everyone can work with is CMake and Autotools. Stick to them.
Well: All systems suck. Some just suck less. as the mutt mailer states. That said, some quick comments:
Qt is pretty nice and well documented, and I like the .pro files one creates. Plus it is reliably cross-platform to book and you now get IDEs etc if you want them.
CMake is what we use at work, and it is cross-platform too, one can get used to it but I still find it quirky.
GNU Autoconf et al is what I use for my projects. Quirky, but I got used to it and a bazillion working examples on the Intertubes.
Scons maybe?
I use mkproject (Make Project) a lot. It is plain autotools stuff as the people suggests to use, but it does load your default configuration kinda like an IDE project generator, very sane minimal yet useful defaults. The rest is up to you to manage by just plain autotools (info configure, info autoconf, info automake are your assistants here, which by the way mkproject follows strictly).
You always start a project with some base procedures, edit a configure.ac edit a Makefile.am, ..., mkproject makes just that without invading the autotools layer or adding new syntax. The cool is that by arguments it personalizes your autotools project from scratch, saving time and errors.
If you use autotools and generate random/a lot of projects, give it a try, it comes with man and info page and even the website tells how to use it.
What would be the best choice of build system for a more than one million line multi platform project, which produces drivers, libraries, command line tools, GUIs, and OS install packages for all the mainstream OSes, using both the GNU and Microsoft toolchains?
Our source code is mainly C, with Python, C# and GNU makefile, and a little C++ and bash. It resides mainly in one repository, but we push source code to various third parties all of whom have their source code code repositories. There is also some interest in keeping the build fast, which might involve splitting up the project.
Currently we use a mixture of GNU make, bash, python and Microsoft's DDKBUILD. The main problems are that we are maintaining a complex set of scripts on top of make and would prefer to use third party (preferably open source) tools, and that cygwin is not proving to be robust on Windows (e.g. fork isn't always possible), and that our current build system does not build or install the toolchain so is vulnerable to tool chain version changes.
I vote for CMake, as a meta-building tool that really rewrite KDE4 build system from scratch -- and make KDE4 now a cross-platform desktop that even running on WindowsCE!
CMake is the carrier porting KDE4 to any OS on earth -- by generating Makefile( or vcprojs in Windows case) for about 40 OSes with relative toolchains!
JetBrains TeamCity works very well in general, so should be worth having on the eval list.
ThoughtWorks Cruise is also in the same space. While its v1, it comes from a stable that's been around for a while.
There's nothing about Team Foundation Server that would make necessarily count it out for your situation, but out of the box it might be more MS-shop centric that the other two I've mentioned.
As a general comment, with the level of variety you have, you definitely want to trial whatever it is you want to use - just because something is supported as a tick on the box doesnt mean its going to suit what oyu're looking for.
Dickson,
Is your build mostly monolithic or do you want to build some libraries separately and assemble them into the larger application? If inter-project dependencies are a big deal, your choices become limited quickly. AnthillPro does it well, and I think TeamCity has some Ivy integration support. From what you're saying, it sounds like this is not an absolute need, but might be helpful in speeding the build. It's certainly a strategy that we've seen a number of teams execute effectively.
Since you're looking at cross-platform (I assume multiple machine) builds, most of the open source tools other than Hudson are ruled out.
A build server comparison matrix is hosted by our friends at Thoughtworks here: confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
Good luck.
You should have CMake on your list of alternatives to investigate. CMake is a meta-tool, i.e. it generates the input to the build-tool of your choice (GNU make, Visual Studio, etc.). I can recommend it strongly.
You may want to look at Cruise. It is built on Java so it will run on any platform that supports that. You can also have multiple build agents on different machines that can perform the different tasks on the different platforms. Thoughtworks is still building it out so some of the functionality is lacking, but it may be a a good option since you are looking for true cross-platform capabilities.
SCons is a cross-platform build system implemented in Python. We use it to build our code on three platforms. It can automatically detect your build tools but you can also put arbitrary Python code in your build script. It also lets you separate your environment setup from description of your project structure, a great feature for reuse of your buidl scripts in different environments. Besides building your project directly, it can also generate Visual Studio project files.