Lodbrok.be
Exploration of Makefiles and configure scripts
CC = gcc
all: hello.c
$(CC) -o hello hello.c
clean:
rm -f *.o hello
Declaration:
command
$
comment
#
dont't run
!
The test
$ touch configure.ac # creates configure.ac - duh $ autoscan -v # creates configure.scan and some other junk $ cp configure.scan configure.ac # create configure.ac and edit it (see diff) $ diff configure.ac configure.scan 5,6c5 < AC_INIT(helloworld, 1.0) < AM_INIT_AUTOMAKE --- > AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS) 20d18 < AC_CONFIG_FILES([Makefile]) # have some problems with config.h.in # trying to remove line below from configure.ac # AC_CONFIG_HEADER([config.h]) # no success, but here is one that do works... $ cat configure.ac AC_INIT(hello) AM_INIT_AUTOMAKE(hello, 1.0) AC_PROG_CC AC_OUTPUT(Makefile) $ aclocal # creates aclocal.m4 $ vi Makefile.am bin_PROGRAMS = hello hello_SOURCES = hello.c ! $ autoheader ! # create config.h.in $ touch NEWS README AUTHORS ChangeLog ! $ automake -a $ automake --add-missing --copy $ autoconf $ ./configure ! $ make dist-gzip $ make dist
In the example below we try to use autoscan. I still recommend it but you have to be carefull and edit configure.ac (scan) by hand. I recommend adding the AUTOMAKE line but not withouth details. For CONFIG_HEADER and autoheader i see no use but trouble - for now. The command aclocal and it output looks obsolete - for now. Automake can be more specific. And make dist equals make dist-gzip.
For my test i created a classic hello.c with Makefile and a GNU build hello package
after gunzip and untar of the GNU build package
du -k hello-1.0 192 hello-1.0
after gunzip and untar of the classic dir with code+Makefile
du -k hello 12 d1
That is a factor 16 in difference, so for small applications this is much overkill. Another thing is that GNU build adds more complexity and less debug transparancy. If you still are able to maintain the Makefile and do not need additional features that automake can provide then i recommend to stick with the common Makefile!