Automake generated files

Maintainers interested in keeping their package buildable from a CVS checkout even for those users that lack maintainer-specific tools might want to provide a helper script or to enhance their existing bootstrap script to fix the timestamps after a cvs update or a git checkout , to prevent spurious rebuilds.

In case of a project committing the Autotools-generated files, as well as the generated. For instance, suppose a developer has modified Makefile. This last change to Makefile. This other developer will not see that Makefile. This way developers are not annoyed by changes to generated files. It does not matter if they all have different versions assuming they are compatible, of course. The drawback is that the CVS repository is not an exact copy of what is distributed and that users now need to install various development tools maybe even specific versions before they can build a checkout.

Therefore the -rpath argument must be explicitly supplied. Here is how the same Makefile. Conditional compilation of sources in a library can be achieved in the same way as conditional compilation of sources in a program see Conditional compilation of sources. So, to mimic the hello example from Conditional compilation of sources , we could build a libhello. Sometimes you want to build libtool libraries that should not be installed. These are called libtool convenience libraries and are typically used to encapsulate many sublibraries, later gathered into one big installed library.

Unlike installed libtool libraries they do not need an -rpath flag at link time this is in fact the only difference. Here is a sample setup merging libtool convenience libraries from subdirectories into one main libtop. When using such a setup, beware that automake will assume libtop. If one of the sublibraries contains non-C source, it is important that the appropriate linker be chosen. One way to achieve this is to pretend that there is such a non-C file among the sources of the library, thus forcing automake to select the appropriate linker.

In effect the file dummy. These are libtool libraries meant to be dlopened. They are indicated to libtool by passing -module at link-time. However, when building a dynamically loadable module you might wish to use a "nonstandard" name. Automake will not complain about such nonstandard names if it knows the library being built is a libtool module, i.

Therefore if -module is set via such a variable, Automake cannot notice it and will proceed as if the library was an ordinary libtool library, with strict naming. See Link mode in The Libtool Manual. The libtool command has two kinds of options: mode-specific options and generic options. They should appear before the mode selection on the command line; in Makefile. Note that the verbosity of libtool can also be influenced by the Automake support for silent rules see How Automake can help in silencing Make.

This is required because the object files that libtool operates on do not necessarily end in. Running this command will install ltmain.

You should execute it before aclocal and automake. People upgrading old packages to newer autotools are likely to face this issue because older Automake versions used to call libtoolize.

Therefore old build scripts do not call libtoolize. Instead, that functionality has been moved into the autoreconf command see Using autoreconf in The Autoconf Manual. If you do not want to remember what to run and when, just learn the autoreconf command.

Hopefully, replacing existing bootstrap or autogen. Sometimes, the same source file is used both to build a libtool library and to build another non-libtool target be it a program or another library. In this trivial case the issue could be avoided by linking libfoo. Technically, it means that we should build foo. The problem is that in the course of creating foo.

A workaround for this issue is to ensure that these two objects get different basenames. As explained in Why are object files sometimes renamed? However as a side effect it will cause prog. Associated with each program is a collection of variables that can be used to modify how that program is built.

There is a similar list of such variables for each library. The canonical name of the program or library is used as a base for naming these variables. In your Makefile. This variable, if it exists, lists all the source files that are compiled to build the program.

These files are added to the distribution by default. When building the program, Automake will cause each source file to be compiled to a single. Normally these object files are named after the source file, but other factors can change this. If a suffix rule exists for turning files with the unrecognized extension into. Otherwise, the file will be ignored as though it were a header file.

By default the output file on Unix systems, the. However, if the option subdir-objects is in effect in the current directory then the. Some projects prefer or require this mode of operation. This may or may not be changed in the future. Automake needs to know the list of files you intend to compile statically.

For one thing, this is the only way Automake has of knowing what sort of language support a given Makefile. There are other, more obscure reasons for this limitation as well. If you intend to conditionally compile source files and use configure to substitute the appropriate object names into, e. For instance, this should be used for objects determined by configure see Building a library.

For instance, this should be used for objects determined by configure see Linking the program. For instance, if your configure. We recommend that you use -l and -L only when referring to third-party libraries, and give the explicit file names of any library built by your package.

This variable is used to pass extra flags to the link step of a program or a shared library. This variable is used to pass extra options to libtool. It is also occasionally useful to have a target program or library depend on some other file that is not in fact part of that target. Each target depends on the contents of such a variable, but no further interpretation is done.

Since these dependencies are associated with the link rule used to create the programs they should normally list files used by the link command.

You can override the linker on a per-program basis. By default the linker is chosen according to the languages used by the program. Automake allows you to set compilation flags on a per-program or per-library basis. A single source file can be included in several programs, and it will potentially be compiled with different flags for each program. This works for any language directly supported by Automake.

When using a per-target compilation flag, Automake will choose a different name for the intermediate object files. Ordinarily a file like sample. See also Why are object files sometimes renamed? On some platforms the allowable file names are very short. For instance, in the following example,. This facility is rarely needed in practice, and we recommend avoiding it until you find it is required.

When no such variable is specified for a target, Automake will define one itself. For example if you have the following somewhere in your Makefile. Default sources are mainly useful in test suites, when building many test programs each from a single source. For instance, in.

Without the last line, they will be built from test1. Another case where this is convenient is building many Libtool modules module n. Finally, there is one situation where this default source computation needs to be avoided: when a target should not be built from sources.

They are substituted by configure. These variables are usually used to build a portability library that is linked with all the programs of the project. We now review a sample setup. First, configure. Here is its Makefile. The library can have any name, of course, and anyway it is not going to be installed: it just holds the replacement versions of the missing or broken functions so we can later link them in.

You should ensure that there is always something to put in libcompat. Occasionally it is useful to know which Makefile variables Automake uses for compilations, and in which order see Flag Variables Ordering ; for instance, you might need to do your own compilation in some special cases.

The contents of this variable are passed to every compilation that invokes the C preprocessor; it is a list of arguments to the preprocessor. For instance, -I and -D options should be listed here. Automake already provides some -I options automatically, in a separate variable that is also passed to every compilation that invokes the C preprocessor.

You can disable the default -I options using the nostdinc option. This matters especially for packages that use header files placed in sub-directories and want to allow builds outside the source tree see Parallel Build Trees a. In that case we recommend using a pair of -I options, such as, e.

Note that the reference to the build tree should come before the reference to the source tree, so that accidentally leftover generated files in the source directory are ignored. It is an older name for the same functionality. This is the variable the Makefile. This is the command used to compile a C source file. The file name is appended to form the complete command line.

This is the command used to link a C program. Automake assumes that the. That is, for a Yacc source file foo. Be aware that header files are generated only when the option -d is given to Yacc; see below for more information about this flag, and how to specify it. Files with the extension. The intermediate files generated by yacc or lex will be included in any distribution that is made. If a Yacc source file is seen, then your configure. The latter is a user variable and the former is intended for the Makefile.

What Automake cannot guess, though, is where this header will be used: it is up to you to ensure the header gets built before it is first used. Typically this is necessary in order for dependency tracking to work when the header is included by another file. If a Lex source file is seen, then your configure. When Yacc or Lex sources are used, automake -a automatically installs an auxiliary program called ylwrap in your package see Programs automake might require. This program is used by the build rules to rename the output of these tools, and makes it possible to include multiple yacc or lex source files in a single directory.

For yacc , simply managing locking as with ylwrap is insufficient. These defines work for bison , byacc , and traditional yacc s. If you find a parser generator that uses a symbol not covered here, please report the new name so it can be added to the list. The command used to compile an Objective C source file. The command used to compile a Unified Parallel C source file. Automake includes some support for assembly code. The variable CCAS holds the name of the compiler used to build assembly code.

This compiler must work a bit like a C compiler; in particular it must accept -c and -o. Only the suffixes. S , and. Any package including Fortran 77 code must define the output variable F77 in configure. The command used to compile a Fortran 77 source file. Automake can handle preprocessing Fortran 77 and Ratfor source files in addition to compiling them 2. This rule runs just the preprocessor to convert a preprocessable Fortran 77 or Ratfor source file into a strict Fortran 77 source file.

The precise command used is as follows:. However, there are many other issues related to mixing Fortran 77 with other languages that are not currently handled by Automake, but that are handled by other packages 3. It is the responsibility of the person writing the Makefile. When a program or library mixes several languages, Automake chooses the linker according to the following priorities. The names in parentheses are the variables containing the link command.

Sometimes this is inconvenient because you are linking against a library written in another language and would like to set the linker more appropriately. Any package including Fortran 9x code must define the output variable FC in configure.

The command used to compile a Fortran 9x source file. Up: Fortran 9x Support [ Contents ][ Index ]. Automake includes support for natively compiled Java, using gcj , the Java front end to the GNU Compiler Collection rudimentary support for compiling Java to bytecode using the javac compiler is also present, albeit deprecated ; see Java bytecode compilation deprecated. Any package including Java code to be compiled must define the output variable GCJ in configure. If it is necessary to pass options to gcj from Makefile.

This requires valac version 0. The generated. The end user does not need to have a Vala compiler installed. This macro takes three optional arguments. The first argument, if present, is the minimum version of the Vala API required to compile this package. For Vala releases, this is the same as the major and minor release number; e.

If a compiler is found and satisfies minimum-version , then action-if-found is run this defaults to do nothing. Otherwise, action-if-not-found is run. If action-if-not-found is not specified, the default value is to print a warning in case no compiler is found, or if a too-old version of the compiler is found.

There is only rudimentary support for other languages, support for which will be improved based on user demand. Some limited support for adding your own languages is available via the suffix rule handling see Handling new file extensions.

As a developer it is often painful to continually update the Makefile. Automake supplies a way to automatically track dependency changes see Automatic Dependency Tracking. Automake always uses complete dependencies for a compilation, including system headers. To this end, dependencies are computed by running all compilations through a special wrapper program called depcomp.

So instead Automake implements dependency tracking at build time. Or, you can invoke automake with the -i option. Dependency tracking is enabled by default. The person building your package also can choose to disable dependency tracking by configuring with --disable-dependency-tracking.

On some platforms, such as Windows, executables are expected to have an extension such as. On these platforms, some compilers GCC among them will automatically generate foo. Automake provides mostly-transparent support for this.

Until the English dictionary is revised, you will have to assist Automake if your package must support those platforms. However, Automake cannot apply this rewriting to configure substitutions. This means that if you are conditionally building a program using such a substitution, then your configure. Sometimes maintainers like to write an explicit link rule for their program. Without executable extension support, this is easy—you simply write a rule whose target is the name of the program.

This might be a nuisance for maintainers who know their package will never run on a platform that has executable extensions. This works in a fairly ugly way; if no-exeext is seen, then the presence of a rule for a target named foo in Makefile. Without the no-exeext option, this use will give a diagnostic. Automake can handle derived objects that are not C programs. Sometimes the support for building such objects must be explicitly supplied, but Automake can still automatically handle installation and distribution.

It is possible to define and install programs that are scripts. When the script is distributed in its final, installable form, the Makefile usually looks as follows:. Scripts can be installed in bindir , sbindir , libexecdir , pkglibexecdir , or pkgdatadir.

When a script needs to be built, the Makefile. For instance the automake program itself is a Perl script that is generated from automake. Here is how this is handled:.

In this situation Automake knows which files should be cleaned and distributed, and what the rebuild rules should look like. Headers can be installed in includedir , oldincludedir , pkgincludedir or any other directory you may have defined see The Uniform Naming Scheme. Usually, only header files that accompany installed libraries need to be installed. Headers used by programs or convenience libraries are not installed. This is clearer for the Makefile.

Missing ones will not appear in the distribution. If these generated headers are needed during the build, you must also ensure they exist before they are used see Built Sources. Automake supports the installation of miscellaneous data files using the DATA family of variables. Such data can be installed in the directories datadir , sysconfdir , sharedstatedir , localstatedir , or pkgdatadir.

By default, data files are not included in a distribution. Ordinarily this is not a problem, because dependencies are distributed sources: they preexist and do not need to be built. Suppose that foo. When it first compiles foo. As a side-effect of this compilation depcomp records the foo. For instance, there might be a rule to build foo.

This time file. For instance, a generated. This means you cannot build an arbitrary target e. Up: Built Sources [ Contents ][ Index ]. Here bindir. We suggest several implementations below. This first implementation will illustrate the bootstrap issue mentioned in the previous section see Built Sources.

Remember, automatic dependency tracking works as a side-effect of compilation, so the dependencies of foo. The symptom is as follows. In this example bindir. This line simply states that bindir.

In other words, it does not help our present problem, and the build would fail identically without it. A solution is to require bindir. If a dependency already exists, it will not hinder the first compilation and will be recorded by the normal dependency tracking code. After this first compilation, the dependency tracking code will also have recorded the dependency between foo.

Adding explicit dependencies like this can be a bit dangerous if you are not careful enough. This is due to the way Automake tries not to overwrite your rules it assumes you know better than it. Always check the generated Makefile. At this point it should be clear that building bindir.

Another attractive idea is to define bindir as a variable or function exported from bindir. Building files from.

Since Automake is primarily intended to generate Makefile. Automake provides some support for Emacs Lisp. The LISP primary is used to hold a list of. Lisp sources are not distributed by default. Byte-compiled Emacs Lisp files are not portable among all versions of Emacs, so it makes sense to turn this off if you expect sites to have more than one version of Emacs installed.

Furthermore, many packages do not actually benefit from byte-compilation. Still, we recommend that you byte-compile your Emacs Lisp sources. It is probably better for sites with strange setups to cope for themselves than to make the installation less nice for everybody else. There are two ways to avoid byte-compiling. Historically, we have recommended the following construct. Emptying this variable explicitly prevents byte-compilation.

Note that these two constructs are not equivalent. The gettext support in Automake requires the addition of one or two subdirectories to the package: po and possibly also intl.

See Building a Shared Library. Automake provides some minimal support for Java bytecode compilation with the JAVA primary in addition to the support for compiling Java to native machine code; see Compiling Java sources using gcj. Note however that the interface and most features described here are deprecated. In any case, the current JAVA primary features are frozen and will no longer be developed, not even to take bug fixes. By default,. Here is a typical setup for distributing.

For instance, a. The flags to pass to the compiler. This is considered to be a user variable see Variables reserved for the user. More flags to pass to the Java compiler.

The value of this variable is passed to the -d option to javac. In the future we will probably handle class path setting differently. Search for a Python interpreter on the system. If an interpreter is found and satisfies version , then action-if-found is run. If action-if-not-found is not specified, as in the following example, the default is to abort configure :.

This is fine when Python is an absolute requirement for the package. Assuming action-if-not-found is used otherwise. The Python version number, in the form major. This value is sometimes needed when building Python extensions.

The directory name for the site-packages subdirectory of the standard Python install tree. This is the directory under pythondir that is named after the package.

It is provided as a convenience. This is the directory where Python extension modules shared libraries should be installed. An extension module written in C could be declared as follows to Automake:.

This works fine in Makefile s, but it makes these variables hard to use in configure. See also Installing to Hard-Coded Locations. Any Texinfo source file should have the. Automake also accepts.

Automake generates rules to build. It is worth noting that, contrary to what happens with the other formats, the generated. This can be changed with the info-in-builddir option.

If the. The file version. Both of these flags hold the version number of your program. They are kept separate for clarity. The version. If you have multiple Texinfo files, and you want to use the version. Often an Info file depends on more than one.

For instance, in GNU Hello, hello. Here is how GNU Hello does it:. By default, Automake requires the file texinfo. In both cases, automake then supplies texinfo. The option no-texinfo. Automake generates an install-info rule; some people apparently use this. This can be prevented via the no-installinfo option. In this case,. The name of the program invoked to build. This variable is defined by Automake. If the makeinfo program is found on the system then it will be used by default; otherwise missing will be used instead.

The command invoked to build. This user variable see Variables reserved for the user is not expected to be defined in any Makefile ; it can be used by users to pass extra flags to suit their needs. Maintainer flags passed to each makeinfo invocation. For instance, the following setting can be used to obtain one single.

The name of the command that converts a. The name of the command that translates a. The name of the command that builds a. The value of this variable should be the relative path from the current Makefile. Man pages are declared using the MANS primary. Man pages are automatically installed in the correct subdirectory of mandir , based on the file extension. File extensions such as. Sometimes developers prefer to name a man page something like foo. Automake also supports this mode. Files listed in such a variable are installed in the indicated section.

If the file already has a valid suffix, then it is installed as-is; otherwise the file suffix is changed to match the section. In this case, rename. However, since the GNU project does not require man pages, many maintainers do not expend effort to keep the man pages up to date. In these cases, the no-installman option will prevent the man pages from being installed by default.

Man pages are not currently considered to be source, because it is not uncommon for man pages to be automatically generated. Therefore they are not automatically included in the distribution. For instance here is how to distribute and install the two man pages of GNU cpio which includes both Texinfo documentation and man pages :. Executables and manpages may be renamed upon installation see Renaming Programs at Install Time. The way to avoid renaming of the foo. Naturally, Automake handles the details of installing your program once it has been built.

A file named in a primary is installed by copying the built file into the appropriate directory. The base name of the file is used when installing. Sometimes it is useful to avoid the basename step at install time. For instance, you might have a number of header files in subdirectories of the source tree that are laid out precisely how you want to install them.

For example:. For most file types, Automake will install multiple files at once, while avoiding command line length issues see Staying below the command line length limit. You should not rely on the order in which files listed in one variable are installed. Likewise, to cater for parallel make, you should not rely on any particular file installation order even among different file types library dependencies are an exception here. Automake generates separate install-data and install-exec rules, in case the installer is installing on multiple machines that share directory structure—these targets allow the machine-independent parts to be installed only once.

The install target depends on both of these targets. While Automake tries to automatically segregate objects into the correct category, the Makefile. All other user-defined prefixes are installed by install-data. It is possible to extend this mechanism by defining an install-exec-local or install-data-local rule. These rules can do almost anything; care is required. Automake also supports two install hooks, install-exec-hook and install-data-hook. These hooks are run after all other install rules of the appropriate type, exec or data, have completed.

So, for instance, it is possible to perform post-installation modifications using an install hook. See Extending Automake Rules , for some examples. If your Makefile. Automake also generates rules for targets uninstall , installdirs , and install-strip. Automake supports uninstall-local and uninstall-hook. Generally the files that can be cleaned are determined automatically by Automake.

Of course, Automake also recognizes some variables that can be defined to specify additional files to clean. When cleaning involves more than deleting some hard-coded list of files, it is also possible to supplement the cleaning rules with your own commands. Simply define a rule for any of the mostlyclean-local , clean-local , distclean-local , or maintainer-clean-local targets see Extending Automake Rules.

A common case is deleting a directory, for instance, a directory created by the test suite:. Since make allows only one set of rules for a given target, a more extensible way of writing this is to use a separate target listed as a dependency:. The dist rule in the generated Makefile. You can set the environment variable TAR to override the tar program used; it defaults to tar. See The Types of Distributions , for how to generate other kinds of archives. Some common examples: compile , config.

These three lists of files are given in their entirety in the output from automake --help. Despite all this automatic inclusion, it is still common to have files to be distributed which are not found by the automatic rules. To emphasize, this copies everything in the directory, including temporary editor files, intermediate build files, version control files, etc. After that you might end up with a no rule to make target You might notice that in your current setup, the release tarball as created by make dist will contain the whatever.

If you don't want this e. My setup for Python wrappers looks as follows:. My setup to deal with the multiple files output by SWIG could be improved , but as these rules are not run by users and it has never caused me any problem, I do not bother.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Asked 8 years, 4 months ago. Active 5 years, 9 months ago. Viewed 3k times.