< Development‎ | Tutorials‎ | KDE3
Revision as of 00:40, 21 February 2007 by Mpyne (talk | contribs) (Development/Documentation/HOWTOs/Makefile.am moved to Development/Tutorials/KDE3/Makefile.am: Consistency with current policy for KDE3-related documentation.)


Note: This page deals with content related to KDE 3. If you are developing for KDE 4, this information might not be valid anymore.
This page needs to be migrated. You can find the original page and its subpages at http://developer.kde.org/documentation/other/makefile_am_howto/en/index.html. Please make use of subpages to structure the wiki, e.g. Policies/Packaging Policy. Read Help:Contents for further details. If in doubt, join #kde-www on irc.kde.org.


This is the Makefile.am HOWTO (English version). Makefile.am is a file used to describe how to build KDE programs. Usually each subdirectory in a KDE module has a Makefile.am. As you may guess from the name, it is supposed to be similar to a Makefile, but it processed first by the KDE build system, then by the autotools to generate the final Makefile.

This is the build system for KDE 3. KDE 4 uses a different build system, CMake.

Makefile.am for a simple program

# Notice the bin_ prefix. bin_PROGRAMS = kdialog

kdialog_SOURCES = kdialog.cpp widgets.cpp kdialog_LDADD = $(LIB_KIO) kdialog_LDFLAGS = $(all_libraries) $(KDE_RPATH)

AM_CPPFLAGS = $(all_includes)



bin means that you want to create something that will install into the bin directory of KDE. *_PROGRAMS means you want to compile a program. Use _SCRIPTS for scripts, etc. Then you can see the name of the program, which is what is used in the lines below to define what has to be done to create that program.


You list all of the source files that need to be compiled for each of the PROGRAMS you have listed. Don't include header files or other files that don't need processed in the build procedure.


This variable is used for each program to define the libraries that the program links to. You can use three types of libraries references:

  1. A library reference as you would pass it to gcc. (Like -lfoo)
  2. A relative path to a Libtool library (Like ../path/to/thelib.la).
  3. A library macro set by the KDE build system. (Like $(LIB_KIO)). It is recommended to use the macro version if set by the KDE build system.

If a library (A) depends on another library (B), you don't need to specify the dependency library (B). But if you do, (e.g. because the dependencies on A might change), make sure you specify A before B. So usually libtool .la libraries are first, then $(LIB_*), then -lfoo if any.


This defines any flags that need to be passed to the linker. Note that the flags do not get passed to the linker by using _LDADD! These can be -L flags (to change the library search path, usually set by configure into a variable). $(all_libraries) contains all the -L flags necessary to find Qt and KDE, so you must have it there. For programs you should also add $(KDE_RPATH), it helps to get installed programs to find their libraries without having to set LD_LIBRARY_PATH.


These specify additional compilation flags. This must contain $(all_includes). This is also where other compile-time flags like -DWITHOUTBUGS and -I$(srcdir)/subdir go.

Insert -I directives before $(all_includes). This ensures that your own headers will be used, not some older installed version.

Note that $(srcdir) and . (the build directory) are always included automatically. You may find that Makefile.am files in KDE still use INCLUDES (the old name for AM_CPPFLAGS), but AM_CPPFLAGS is the recommended way to add include paths and other compilation flags.


There is also KDE_CXXFLAGS. It is always appended to the end of the other flags used in the build, so it can undo one of the flags set by the KDE build framework. This is the case for exception handling support, which is disabled by default. If you want to use exception handling you need to write KDE_CXXFLAGS = $(USE_EXCEPTIONS)


METASOURCES = AUTO is the magic line that makes the KDE build system take care of the moc files automatically. It is the recommended way if all your .cpp/.cc files include their .moc file (this is the best way since it gives faster compilation), or if you are compiling a single binary/library.

In case you have multiple binaries/libraries in the same directory, you might need to use the longer form of libfoo_la_METASOURCES = myfile.moc myotherfile.moc mybinary_METASOURCES = someotherfile.moc

This page was last edited on 29 June 2011, at 20:52. Content is available under Creative Commons License SA 4.0 unless otherwise noted.