问题
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?
回答1:
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.
回答2:
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.
回答3:
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?
回答4:
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.
来源：https://stackoverflow.com/questions/1596279/why-has-nobody-created-an-open-source-build-system-for-the-brain-dead