2
votes

UPDATE: First problem solved, second one described at the bottom of this post.

UPDATE2: Second problem solved as well.

I'm trying to learn about setting up GNU build tools (autoconf/automake) for a very simple GTK+2 C application. I've followed this tutorial and this one that deals with sub directories, but I'm running into a problem where my source directory (in the src sub-directory) is not generating a Makefile, though the parent directory's Makefile is getting generated.

First, here is my folder structure:

app/src
  - main.c
  - main.h
  - Makefile.am
app
  - configure.ac
  - Makefile.am
  - aclocal.m4
  (... other generated files ...)

Here are the contents of the important files:

app/configure.ac:

AC_PREREQ([2.63])
AC_INIT(app, 0.1)
AM_INIT_AUTOMAKE(app, 0.1)
AC_CONFIG_SRCDIR([src/main.h])
AC_CONFIG_HEADERS([config.h])

# Checks for programs.
AC_PROG_CC

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.
AC_CONFIG_FILES([Makefile], [src/Makefile])
AC_OUTPUT

app/Makefile.am:

SUBDIRS = src

app/src/Makefile.am:

bin_PROGRAMS = app

app_SOURCES = main.c
app_LDADD = `pkg-config --cflags --libs gtk+-2.0`

Here is what happens when I run the following commands:

$ autoconf
$ automake -a
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
configure: creating ./config.status
config.status: creating Makefile
./config.status: line 1153: src/Makefile: No such file or directory
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands

When I check, the main app folder gets a Makefile and Makefile.in, but the src folder still only has the Makefile.am. Any ideas?

UPDATE: I made the changes mentioned by adl, namely, I removed the square brackets and comma from the AC_CONFIG_FILES command and removed the app name/version from the AM_INIT_AUTOMAKE command. I also changed the app_LDADD command in src/Makefile.am to app_LDFLAGS. This has fixed my initial problem of not getting through a configure, but now it isn't looking for the gtk libraries. When I do a make I get something like the following:

$ make
make  all-recursive
make[1]: Entering directory `/home/adam/Development/app-0.1'
Making all in src
make[2]: Entering directory `/home/adam/Development/app-0.1/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" \
      -c -o main.o `test -f 'main.c' || echo './'`main.c; \
    then mv -f ".deps/main.Tpo" ".deps/main.Po"; \
    else rm -f ".deps/main.Tpo"; exit 1; \
    fi
main.c:3:21: error: gtk/gtk.h: No such file or directory
In file included from main.c:4:
main.h:4: error: expected specifier-qualifier-list before ‘GtkWidget’

Here is what I get with pkg-config:

$ pkg-config --libs --cflags gtk+-2.0
-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0

I'm pretty sure I'm doing something wrong in my src/Makefile.am, but I don't know what. If it helps, my configure script does not appear to be looking for any gtk libs.

UPDATE2:

So the basic solution for the problem in update1 seems to be that I needed to add the following check to my configure.ac file:

PKG_CHECK_MODULES(GTK, [gtk+-2.0 >= 2.12])

PACKAGE_CFLAGS="-g -Wall $GTK_CFLAGS"
PACKAGE_LIBS="-g $GTK_LIBS"
PACKAGE_LDFLAGS="-export-dynamic $GTK_LDFLAGS"

AC_SUBST([PACKAGE_CFLAGS])
AC_SUBST([PACKAGE_LIBS])
AC_SUBST([PACKAGE_LDFLAGS])

This gets added to the checks for programs section under AC_PROG_CC. What this does is tell configure to check for the gtk+-2.0 library. The upper case GTK seems to be an arbitrary variable name, and the CFLAGS, LIBS, and LDFLAGS (and probably more) gets added to it dynamically so that you can generate the PACKAGE_* variables. The AC_SUBST seems to make it so you can access the PACKAGE* variables in your Makefile.am's. FYI, the -export-dynamic flag is added so that you can use glade/gtkbuilder files (I'm sure there are other reasons, but I'm still at a very basic level of understanding).

In src/Makefile.am, you should have:

bin_PROGRAMS = app

app_SOURCES = main.c main.h 
app_LDADD = @PACKAGE_LIBS@
app_LDFLAGS = @PACKAGE_LDFLAGS@
INCLUDES = @PACKAGE_CFLAGS@

This seems to be all you need for a basic gtk+-2.0 C app. It has actually inspired me to write a simple tutorial for setting up a C gtk app that uses autotools. There is a definite lack of recent beginner documentation/information in this field.

4

4 Answers

2
votes

Two issues in your configure.ac file. First, the syntax of your AM_INIT_AUTOMAKE invocation is 10 year old, I suspect you copied it from a very old tutorial (hint: the Automake manual has a tutorialish introduction). You've already passed the package and version to AC_INIT, there is no need to repeat that in AM_INIT_AUTOMAKE. Second, the list of files passed to AC_CONFIG_OUTPUT should be a space-separated list given as first argument.

In other words, your configure.ac should look like

AC_PREREQ([2.63])
AC_INIT([app], [0.1], [your@email])
AM_INIT_AUTOMAKE([-Wall])
AC_CONFIG_SRCDIR([src/main.h])
AC_CONFIG_HEADERS([config.h])
AC_PROG_CC
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT

Note there is no coma on the AC_CONFIG_FILES line.

The -Wall option will cause automake to output more warnings (this really is an automake option, not a gcc option), it's probably safer if you discover these tools.

This should fix your configure problem. Then I suspect you'll probably have to split your app_LDADD line into app_CPPFLAGS and app_LDFLAGS.

1
votes

A few more issues that haven't been mentioned yet:

  • Use autoreconf to (re)generate configure and Makefile.in. It calls the requisite tools in the correct order.
  • Prefer using the make macros (“$(FOO)”) to the Autoconf substitutions (“@FOO@”) in your makefile. The advantage of the former is that they can be overridden at make time should that be necessary.
  • I'd encourage you to create a separate build directory and run configure there rather than building in the source directories. This is a setup that you probably don't want to break; and if you aren't testing it, you can inadvertently break it.
0
votes

Rather than adding GTK_CFLAGS and GTK_LDFLAGS to your PACKAGE_CFLAGS, you can simply do:

app_LDADD = @PACKAGE_LIBS@ @GTK_LIBS@

or, if every app depends on gtk, just do

LDADD = @GTK_LIBS@

Specifying -g and -Wall the way you are is not really a good thing. You can do it more easily by defining AM_CFLAGS, and while that's fine for -Wall, you really don't want -g in there. The default configure will add -g to CFLAGS, and if the user overrides CFLAGS when configure is run, you should trust them to know what they're doing and give them the freedom to skip -g. If you are adding -g for your own convenience (so you don't need to specify -g when you specify CFLAGS at configure time), it would be more appropriate to use a CONFIG_SITE rather than hardcoding the -g in you project's build files.

-1
votes

Another option for this could be the following:

AM_PATH_GTK_2_0([Min version], [Succes], [Failure])
AM_PATH_GLIB_2_0([Min version], [Succes], [Failure])

It's always a good idea to take a look at what your aclocal directory (/usr/aclocal) holds as macro possibilities. Also don't forget to run aclocal so that the required M4 macros gets copied to aclocal.m4.