views:

311

answers:

3

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?

+3  A: 

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?
Dirk Eddelbuettel
Even Qt have this problem, trying to find a build system that is simple but powerful - http://labs.trolltech.com/blogs/2009/10/14/to-make-or-not-to-make-qmake-and-beyond-redux/
Martin Beckett
They are not withdrawing, they are simply trying to make it better still and make more customers on more platforms happy. It is a pretty decent system -- but as I said at the outset, not one is perfect.
Dirk Eddelbuettel
+1  A: 

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.

Pavel Shved
Harsh advice :-)
James Morris
+5  A: 

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.

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.

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

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.

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.

Patrick Anderson
Nice post! I took the liberty to edit the list a bit more in the wiki-style used around here.
Dirk Eddelbuettel
I've added SCons.
J.F. Sebastian
I've started using Premake. It is quick and easy to get started with through its simple to understand syntax. Thanks for suggesting!
James Morris
**Spray** link does not work.
Sorin Sbarnea