Automake 1.11 manual

This would be a bug in kdevelop's automake scripts. Linking to your actual bug report would have been helpful. Here's the report where they tell you they're not going to fix that version of KDevelop since it's too old, uses KDE3, and is unmaintained. This implies the existence of a newer kdevelop that is maintained and uses KDE4. Time to upgrade your desktop to KDE4. Or downgrade automake to 1. This is far from the first time automake has flagrantly broken itself, though.

It's also bloated itself beyond dreams of bloat. You might be better off with makefiles and DDD than an all-singing all-dancing automake-based monstrosity. Last edited by Corona; at PM.. Find all posts by Corona Ok, It is dificult: KDevelp4 should not be used for production code.

It's a shame. Originally Posted by lucelio. Show Posts. Please run the following command info automake to access the complete documentation. Check Out this Related Man Page. Hey, i'm trying to use httptunnel and it won't let me configure it. Dependencies problem GNU automake. I am using the GNU automake. I have created the Configure. I have basically added another project OpenCV to my eclipse workspace and want to reference this in the build.

I have set Eclipse up to include the Cpp files These other packages should just appear as subdirectories of their parent package. So although it appears to be embedded in another package, it can still be used separately. The historical default is to search for these auxiliary scripts in the parent directory and the grandparent directory. Packages that do not use Automake need more work to be integrated this way. See Third-Party Makefile s. In order to build a program, you need to tell Automake which sources are part of it, and which libraries it should be linked with.

This section also covers conditional compilation of sources or programs. Most of the comments about these also apply to libraries see Building a library and libtool libraries see Building a Shared Library.

In this simple case, the resulting Makefile. Associated with each program are several assisting variables that are named after the program. These variables are all optional, and have reasonable defaults. This causes each mentioned. Then all are linked to produce hello.

Multiple programs can be built in a single directory. Sometimes, multiple programs are built in one directory but do not share the same link-time requirements. For instance, in GNU cpio, pax , cpio and mt are linked against the library libcpio. However, rmt is built in the same directory, and has no such link requirement. Also, mt and rmt are only built on certain architectures. It is also occasionally useful to have a program depend on some other target that is not in fact part of that program.

Each program depends on the contents both variables, but no further interpretation is done. Since these dependencies are associated to the link rule used to create the programs they should normally list files used by the link command. Instead, write the file name of the library explicitly as in the above cpio example.

Use -l only to list third-party libraries. Automake will give an error if you try to do this. Fortunately there are two other ways to achieve the same result. Automake must know all the source files that could possibly go into a program, even if not all the files are built in every circumstance. For instance, if hello-linux. An often simpler way to compile source files conditionally is to use Automake conditionals.

For instance, you could use this Makefile. In this case, configure. Sometimes it is useful to determine the programs that are to be built at configure time. For instance, GNU cpio only builds mt and rmt under special circumstances. The means to achieve conditional compilation of programs are the same you can use to compile source files conditionally: substitutions or conditionals.

In this case, you must notify Automake of all the programs that can possibly be built, but at the same time cause the generated Makefile. You can also use Automake conditionals see Conditionals to select programs to be built. Building a library is much like building a program.

Libraries can be installed in libdir or pkglibdir. For instance, to create a library named libcpio. This should be used for objects determined by configure. Again from cpio :. Be careful when selecting library components conditionally. Because building an empty library is not portable, you should ensure that any library always contains at least one object. In the following example, the program cpio is statically linked with the library libcpio. Building shared libraries portably is a relatively complex matter.

Libtool abstracts shared and static libraries into a unified concept henceforth called libtool libraries. Libtool libraries are files using the. Their exact nature cannot be determined until. Because object files for shared and static libraries must be compiled differently, libtool is also used during compilation.

Object files built by libtool are called libtool objects : these are files using the. Libtool libraries are built from these libtool objects. You should not assume anything about the structure of. There are situations where you may have to refer to these, for instance when expressing dependencies for building source files conditionally see Libtool Libraries with Conditional Sources.

This offers a portable dlopening facility to load libtool libraries dynamically, and can also achieve static linking where unavoidable. Before we discuss how to use libtool with Automake in detail, it should be noted that the libtool manual also has a section about how to use Automake with libtool see Using Automake with Libtool in The Libtool Manual.

For instance, to create a libtool library named libgettext. If gettext. Headers listed in the latter should be internal headers that are not part of the public interface. A package can build and install such a library along with other programs that use it.

The following example builds a program named hello that is linked with libgettext. Whether hello is statically or dynamically linked with libgettext. The important implementation detail you have to be aware of is that the place where a library will be installed matters to libtool: it needs to be indicated at link-time using the -rpath option.

For libraries whose destination directory is known when Automake runs, Automake will automatically supply the appropriate -rpath option to libtool. 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. Author Topic: bootstrap not compatible with automake 1. SharkCZ Almost regular Posts: The bootstrap script is not compatible with automake 1.

See attachment for a fix. Posts: It's a known issue, and I already have a different patch in my working-copy. I did not yet apply it, because there have not been any responses except from the one posted by KirkD.