Tutorials for setting up a robust small-to-medium project *nix build

Question

I'm mostly a spoiled Windows + Visual Studio (or Borland C++ or whatever, in the past) developer. Although my first contact with Unix was around 20 years ago, and I've used Linux on-and-off for some years, I have only a very limited idea of how to set up a build on a *nix system.

For example, I'm OK with the basics of make - I can get a number of files to compile and link. But I don't really know how to set things up to cope with multiple configurations - how to get all the object files and targets for the release version to go to different folders from the debug version etc etc. Yes, I can RTFM and improvise something, but it's a fair guess that I'd improvise something stupid, overcomplex, fragile and WTF, where it'd make so much more sense to copy a common convention if only I knew what the common conventions are.

Also, I can run a configure script, and I'm vaguely aware that they're associated with autoconf, whatever that is, but I have little idea if/why/how I should set this kind of stuff up in my own projects.

Hopefully, this is enough to give the general idea of what I'm looking for. Of course I could ask/search specific questions here, but that assumes I know all the right questions to ask which I almost certainly don't. So - any pointers?

EDIT

Just thought I'd update this with some longer-term experience.

I tried using premake for a while, but couldn't live with it in the long run. In substantial part there's a dislike of Lua behind that.

Now, I'm using cmake. It generates makefiles/visual studio projects/whatever. It has (so far) handled everything I've needed to do, including support for unit testing and custom build steps. And as I got used to the cmake way of doing things, I found it was a good way, allowing me to easily use multiple sets of tools at once - I can be checking test coverage in MinGW GCC while simultaneously debugging in Visual Studio.

That reveals, of course, that I'm still mostly working in Windows - but switching back and forth is easier than ever.

The downsides of cmake...

1. Although it generates makefiles/whatever, it can't really be seen as a makefile generator. The resulting makefiles are dependent on cmake being installed. To be honest, I don't really understand why they don't drop makefiles altogether for makefile platforms and just do the building directly, slightly reducing the potential for problems.
2. It wasn't easy to get started.

The second point has mostly been resolved by asking questions here...

• http://stackoverflow.com/questions/3100252/how-do-i-fix-this-cmake-file-problem-linking-to-imported-library
• http://stackoverflow.com/questions/3134660/how-to-apply-different-compiler-options-for-different-compilers-in-cmake
• http://stackoverflow.com/questions/3249459/for-the-cmake-include-command-what-is-the-difference-between-a-file-and-a-modu
• http://stackoverflow.com/questions/3305545/how-to-adapt-my-unit-tests-to-cmake-and-ctest

Answer 1

I would stay away from autoconf until you actually need it as it is pretty complex to use, and in most small projects, make is all you need...

I don't have a tutorial, but I will give you an extremely amazing(and portable between both BSD and GNU make) makefile to start with for small projects. I dug it out of the original BSD 4.3 assembler(as)

HDRS = project.h
OBJS = main.o 
LDFLAGS = 
project: ${OBJS}
    ${CC} ${LDFLAGS} ${OBJS} -o project
.c.o: ${HDRS}
    ${CC} ${CFLAGS} -c $*.c
clean:
    rm -f *.o ${OBJS} project *.core a.out errs core

just replace Project with your projects name and such..

edit: technically, you need a BSD 3 clause license for Berkeley... as per:

 * Copyright (c) 1982 Regents of the University of California.
 * All rights reserved.  The Berkeley software License Agreement
 * specifies the terms and conditions for redistribution.

Answer 2

I'd strongly suggest using one of the newer cousins of Make instead of autoconf or makefiles for smaller projects. One of the best ones for you (and the one I mostly love) could be premake4. Why do I suggest it? Because it's extremely simple to use, yet quite powerful, and capable of producing GNU Makefiles, Visual Studio projects, Code::Blocks projects and many more. And the premake files are very clear and readable, using the Visual Studio nomenclature that you're already familliar with.

Here's an example:

-- A solution contains projects, and defines the available configurations
solution "MyApplication"
   configurations { "Debug", "Release" }

   -- A project defines one build target
   project "MyApplication"
      kind "ConsoleApp"
      language "C++"
      files { "inc/**.h", "src/**.cpp", "main.cpp" }

      configuration "Debug"
         defines { "DEBUG" }
         flags { "Symbols" }

      configuration "Release"
         defines { "NDEBUG" }
         flags { "Optimize" }