(Commit initial migration of Makefile.am howto)
m (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.
# 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)
METASOURCES = AUTO
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:
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.
|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