[geeks] UNIX development and makefile discussion

[Jochen Kunz]

On Wed, 14 Aug 2013 15:04:39 +0000
microcode at zoho.com wrote:

> I have heard of cmake and of course autotools but I don't know big a project
> has to be before that stuff starts making sense.
Depends on your preferences. I use cmake for anything of more then
probably three or four files. I definately use it when I build a
(shared) library.

> What really strikes me
> about UNIX is how much the tools get in my way and take up much of my time.
Learning curve. The tools will free much of your time once you got used
to them. ;-)

> If cmake is warranted for a project with a dozen source files
I'd say yes, it is warranted. But as you are at the start of the
learning curve you may postpone the cmake lesson to a later time. :-)

> > Think of it as "meta-make". cmake eases the tedious process of writing
> >  makefiles and organizing them considerably. 
> At this point writing makefiles isn't a major issue for me.
cmake does more. E.g. it scans dependencies, inside your project and to
external dependencies. It builds install targets. It cares about the
details of linking and building (shared) libraries. It assists you in
setting up compile time options, ...

> In this project I have different functional areas that I have separate
> makefiles for that all build and run fine. The problem is and it's really a
> good problem to have is that each of the functional areas are starting to
> rely on code that could be shared.
Then share the code. Build a (shared) library that is used by all your
different programms in the project. Make the executables only a thin
layer around the functionality in the (shared) library.

A possible directory hierarchy for your source code could be:
$PROJECT/
    $PROJECT.pc.in
    lib/
        internal.h
        public_1.c
        public_2.c
        public_3.c
    include/$PROJECT/
        $PROJECT.h
        public_1.h
        public_2.h
        public_3.h
    bin/
        prog_1.c
        other_prog_main.c
        other_prog_additional_stuff.c

($PROJECT is a "variable" holding the name of your project.)
Put common code in the "lib" directory. There you put headers that are
only used inside the library too. Headers that define the interface of
the library go into "include/$PROJECT". "include/$PROJECT/$PROJECT.h"
includes all other public headers. So users of the lib only need to
#include <$PROJECT/$PROJECT.h>
to get it all. The "bin" directory contains two executables, "prog_1"
and "other_prog". Where the later is build out of two C-files.
"$PROJECT.pc.in" is a template file to generate a pkg-config(1) package
description file. You don't need this, but it will ease things when you
use the library in other projects.

This is just a simple sugestion. You may split up the lib code into
several different libraries and possibly subdirectories below the "lib"
directory. The same for the executables. You may add one directory per
executable below "bin" to hold all the code for each single executable.
-- 


\end{Jochen}

\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}