C/C++ Programming Pearls
Simple Compile 
 
Prog1.c needs the test function in  test.c
To compile, so that both programs work together, do the following:
     gcc -o prog test.c prog1.c

However, if you want to create your own library, then, run the following:
     gcc -c test.c
     ar r libpersonal.a test.o
     ranlib libpersonal.a 

or, the ar and ranlib command can be combined as follows:
    ar rs libpersonal.a test.o

next, create the header file, libpersonal.h
    /* libpersonal.h: routines in libpersonal.a */
    extern int test(char *);

To compile the program with the static library:
   gcc -I .  -L .  -o prog1 prog1.c -lpersonal

The -I . tells the gcc to look in the current directory for the new include file. and
-L ., tells gcc to look for the libpersonal.a, library in the current directory as well.
    
If this example didn't work, make sure you added #include <libpersonal.h> to prog1.c
test.c 
#include <stdio.h>
int test(char *t)
{
  printf("%s\n",t);
}
prog1.c 
/*
   program: prog1.c
   dependences: test.c

   compiling this program:
   gcc -o prog test.c prog1.c
*/
#include <stdio.h>
int
main(int argc, char **argv)
{
  test("this depend on test.c ");
}
Creating Your Own configure/Makefile
The following tools can help you create a configuration and Makefile:
  • autoscan
  • autoconf
  • aclocal
  • automake -a
Assume the following directory structure below: 
project1--------
               \---src
                      \--- stl
                      |       \--- stringSTL.cc
                      |
                      \--- prog1
                               \--- prog1.c, test.c
Two programs, stringSTL (a C++ program), and prog1.c ( a C program that depends on test.c). Note, that this is really two separate programs under one project. So currently this is all that exist in the directory tree structure.
The first step is to run autoscan from the project1 directory
$cd project1
$autoscan
$cp configure.scan configure.in
This will produce configure.scan, which in the last command above gets copied to configure.in. Now, what's in configure.in will vary depending upon which version is used. Regardless, configure.in will have to be edited. Below, is what is should look like:
configure.in 
dnl Process this file with autoconf to produce a configure script.
AC_INIT(src/prog1/prog1.c src/stl/stringSTL.cc)
AM_INIT_AUTOMAKE(project1,0.0.1)
AC_PROG_CC
AC_PROG_CXX
AC_PROG_INSTALL



dnl Checks for libraries.

dnl Checks for header files.
AC_HEADER_STDC
dnl Checks for typedefs, structures, and compiler characteristics.

dnl Checks for library functions.

AC_OUTPUT(Makefile src/Makefile src/prog1/Makefile src/stl/Makefile)

Next, you will need to create serveral Makefile.am files, in each of the directories.
project1/Makefile.am 
SUBDIRS = src
project1/src/Makefile.am 
SUBDIRS = prog1 stl
project1/src/prog1/Makefile.am 
bin_PROGRAMS = prog1
prog1_SOURCES = prog1.c test.c
project1/src/stl/Makefile.am 
bin_PROGRAMS = stringSTL
stringSTL_SOURCES = stringSTL.cc

Next, run the following: 
$autoconf
$aclocal
$automake -a
automake -a may alert you to missing files COPYING, INSTALL, NEWS, README, AUTHORS, and ChangeLog. If so, these files can be created as follows: 
$touch COPYING INSTALL README NEWS AUTHORS ChangeLog TODO
It's best to run this command after running automake -a because some versions of automate will create an INSTALL file, plus a few some of the other files. touch will not overwrite any of these; although, you may get a permissions error, which can be ignored.
Next, run automake -a again 
$automake -a
If you find errors in configure.in it may be necessary to delete configure, and all config.* files. Do not delete configure.in. Then, run autoconf, aclocal, automake -a again.
Steps
SourceForge.net Logo