Automake install-data-local

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 which are laid out precisely how you want to install them.

For example:. Automake generates separate install-data and install-exec targets, in case the installer is installing on multiple machines which share directory structure--these targets allow the machine-independent parts to be installed only once.

However --libdir takes precedence over it. Print the path of the installation directory containing Automake-provided scripts and data files e. When used with --add-missing , causes installed files to be copied. The default is to make a symbolic link.

When used with --add-missing , causes standard files to be reinstalled even if they already exist in the source tree. This involves removing the file from the source tree before creating the new symlink or, with --copy , copying the new file. Set the global strictness to foreign. For more information, see Strictness. Set the global strictness to gnits.

Set the global strictness to gnu. This is the default strictness. This disables the dependency tracking feature in generated Makefile s; see Automatic dependency tracking. This enables the dependency tracking feature. This feature is enabled by default. This option is provided for historical reasons only and probably should not be used. Ordinarily automake creates all Makefile. This option causes it to only update those Makefile. Put the generated Makefile. Ordinarily each Makefile.

This option is deprecated and will be removed in a future release. Output warnings about a category of potential problems with the package. These are not universally supported, but are more portable than the other non-portable constructs diagnosed by -Wportability. These warnings are turned on by -Wportability but can then be turned off specifically by -Wno-portability-recursive. Extra portability issues, related to rarely-used tools such as the Microsoft lib archiver. For instance, -Wno-syntax will hide the warnings about unused variables.

This warning is never treated as an error. This is an experimental feature. Next: Directories , Previous: Creating a Makefile. Some autoconf macros are required and some variables must be defined in configure. Automake will also use information from configure. Automake also supplies some Autoconf macros to make the maintenance easier.

These macros can automatically be put into your aclocal. Next: Other things Automake recognizes , Up: Scanning configure. The one real requirement of Automake is that your configure. This macro does several things that are required for proper Automake operation see Autoconf macros supplied with Automake.

A listed file is considered to be an Automake generated Makefile if there exists a file with the same name and the.

If no such file exists the output file is not considered to be generated by Automake. Finally, rebuild rules are generated in the Automake Makefile existing in the subdirectory of the output file, if there is one, or in the top-level Makefile otherwise. If part of the specification uses shell variables, automake will not be able to fulfill this setup, and you will have to complete the missing bits by hand. For instance, on. However the rebuild rule will not depend on input , and this file will not be distributed either.

For instance, here is how the Automake package itself generates versioned scripts for its test suite:. Note that you should not use shell variables to declare Makefile files for which automake must create Makefile. In the very hairy case that your setup requires such use of variables, you will have to tell Automake which Makefile. Next: Auto-generating aclocal. Every time Automake is run it calls Autoconf to trace configure. This way it can recognize the use of certain macros and tailor the generated Makefile.

Currently recognized macros and their effects are:. Automake will ensure that config. Automake will look for various helper scripts, such as install-sh , in the directory named in this macro invocation. The full list of scripts is: ar-lib , config.

Not all scripts are always searched for; some scripts will only be sought if the generated Makefile. For mdate-sh , texinfo. For the rest, the standard location is the first one of.

Automake will generate rules to rebuild these headers from the corresponding templates usually, the template for a foo.

There are no rebuild rules for links. This is required if any libraries are built in the package. This is required if any Objective C source is included. This is required if any Fortran 77 source is included. See Autoconf macros supplied with Automake. This macro is distributed with Autoconf version 2. Automake will turn on processing for libtool see Introduction in The Libtool Manual. If a Yacc source file is seen, then you must either use this macro or define the variable YACC in configure.

If a Lex source file is seen, then this macro must be used. It will also automatically distribute the file. The first argument is automatically defined as a variable in each generated Makefile.

This macro allows automake to detect subsequent access within configure. This macro is required for packages that use GNU gettext see Gettext.

It is distributed with gettext. This macro adds an --enable-maintainer-mode option to configure. Prevent Automake from defining a variable var , even if it is substituted by config. Normally, Automake defines a make variable for each configure substitution, i. This macro prevents that definition from Automake. Files included by configure.

They will also appear as dependencies in Makefile rules. Automake includes a number of Autoconf macros that can be used in your package see Autoconf macros supplied with Automake ; some of them are required by Automake in certain situations. These macros must be defined in your aclocal. The aclocal program will automatically generate aclocal. This provides a convenient way to get Automake-provided macros, without having to search around. The aclocal mechanism allows other packages to supply their own macros see Writing your own aclocal macros.

You can also use it to maintain your own set of custom macros see Handling Local Macros. At startup, aclocal scans all the.

Then it scans configure. Any mention of one of the macros found in the first step causes that macro, and any macros it in turn requires, to be put into aclocal. Putting the file that contains the macro definition into aclocal.

This makes the package smaller, eases dependency tracking, and cause the file to be distributed automatically. See Handling Local Macros , for an example. Any macro that is found in a system-wide directory or via an absolute search path will be copied. The contents of acinclude. We recommend against using acinclude. While computing aclocal. Look for the automake-provided macro files in dir instead of in the installation directory.

However --automake-acdir takes precedence over it. Look for the system-wide third-party macro files and the special dirlist file in dir instead of in the installation directory. Run command on the M4 file that would be installed or overwritten by --install. This option implies --install and --dry-run. Do not overwrite or create aclocal. Note that this will happen also if dir is an absolute path. Always overwrite the output file.

The default is to overwrite the output file only when needed, i. This option forces the update of aclocal. Prints the name of the directory that aclocal will search to find third-party. When this option is given, normal processing is suppressed. This option was used in the past by third-party packages to determine where to install.

By default, aclocal searches for. This is where the. This directory is intended for third party. To find the compiled-in value of acdir , use the --print-ac-dir option see aclocal Options.

As an example, suppose that automake Then, the search path would be:. Note however that these options are only intended for use by the internal Automake test suite, or for debugging under highly unusual situations; they are not ordinarily needed by end-users. As explained in see aclocal Options , there are several options that can be used to change or extend this search path. Any extra directories specified using -I options see aclocal Options are prepended to this search list. There is a third mechanism for customizing the search path.

If a dirlist file exists in acdir , then that file is assumed to contain a list of directory patterns, one per line. Then, the search path would be. Thus, the default search directories are.

This is inconvenient. Similarly, dirlist can be handy if you have installed a local copy of Automake in your account and want aclocal to look for macros installed at other places on the system. The fourth and last mechanism to customize the macro search path is also the simplest. Also note that, if the --install option is used, any.

In this case, serial numbers in. This is a possible future incompatibility! This can be used by libraries that want to supply their own Autoconf macros for use by other programs.

When the library is installed, it installs this macro so that aclocal will find it. This is as simple as writing:. Each file should have no side effects but macro definitions. Starting with Automake 1. We realize this annoys some people, because aclocal was not so strict in the past and many third party macros are underquoted; and we have to apologize for this temporary inconvenience.

The reason we have to be stricter is that a future implementation of aclocal see The Future of aclocal will have to temporarily include all of these third party.

Doing so should alleviate many problems of the current implementation; however, it requires a stricter style from macro authors. Hopefully it is easy to revise the existing macros. For instance,. For consistency we like to quote even arguments such as 2. If you have been directed here by the aclocal diagnostic but are not the maintainer of the implicated macro, you will want to contact the maintainer of that macro. Another situation where aclocal is commonly used is to manage macros that are used locally by the package; Handling Local Macros.

Feature tests offered by Autoconf do not cover all needs. People often have to supplement existing tests with their own macros, or with third-party macros. The first possibility the historical practice is to list all your macros in acinclude. This file will be included in aclocal. However if it contains numerous macros, it will rapidly become difficult to maintain, and it will be almost impossible to share macros between packages.

The second possibility, which we do recommend, is to write each macro in its own file and gather all these files in a directory. Macros not found locally will still be searched in system-wide directories, as explained in Macro Search Path. Custom macros should be distributed for the same reason that configure. However there is no consensus on the distribution of third-party macros that your package may use. Many libraries install their own macro in the system-wide aclocal directory see Writing your own aclocal macros.

For instance, Guile ships with a file called guile. Technically, that means a user who needs to rebuild aclocal. This is probably OK, if Guile already is a requirement to build the package. However, if Guile is only an optional feature, or if your package might run on architectures where Guile cannot be installed, this requirement will hinder development.

Since Automake 1. Then the locally installed macros will have precedence over the system-wide installed macros each time aclocal is run again. One reason why you should keep --install in the flags even after the first run is that when you later edit configure. Another one is that serial numbers see Serial Numbers can be used to update the macros in your source tree automatically when new system-wide versions are installed.

A serial number should be a single line of the form. It should appear in the M4 file before any macro definition. It is a good practice to maintain a serial number for each macro you distribute, even if you do not use the --install option of aclocal : this allows other people to use it. This makes it easier to tell which of two M4 files is newer. Such a line should appear in the M4 file before any macro definition. Normally these serial numbers are completely ignored by aclocal and autoconf , like any genuine comment.

Note that a serial number applies to a whole M4 file, not to any macro it contains. A file can contain multiple macros, but only one serial. Here is a use case that illustrates the use of --install and its interaction with serial numbers. The first time we run aclocal --install , it will notice that. Because both files have the same serial number, aclocal uses the first it found in its search path order see Macro Search Path.

Local directories specified with -I are always searched before system-wide directories, so a local file will always be preferred to the system-wide file in case of equal serial numbers. Now suppose the system-wide third-party macro is changed.

This can happen if the package installing this macro is updated. When aclocal sees a greater serial number, it immediately forgets anything it knows from files that have the same basename and a smaller serial number.

This brings us back to a situation similar to that at the beginning of our example, where no local file defined the macro. MyPackage just had its macro updated as a side effect of running aclocal. Finally, note that the --force option of aclocal has absolutely no effect on the files installed by --install.

For instance, if you have modified your local macros, do not expect --install --force to replace the local macros by their system-wide versions. Previous: Serial Numbers , Up: Auto-generating aclocal. Ideally, aclocal should not be part of Automake. The fact that some people install Automake just to use aclocal , but do not use automake otherwise is an indication of how that feature is misplaced. The new implementation will probably be done slightly differently.

We have no idea when and how this will happen. This has been discussed several times in the past, but someone still has to commit to that non-trivial task. There is a simple precaution that you may take to make that switch more seamless: never call aclocal yourself. If otherwise you used to call aclocal directly yourself or from some script, you will quickly notice the change.

Many packages come with a script called bootstrap or autogen. In fact, this is precisely what autoreconf can do for you. If your package has such a bootstrap or autogen. Previous: Auto-generating aclocal. Automake ships with several Autoconf macros that you can use from your configure. When you use one of them it will be included by aclocal in aclocal. In this form, there are two required arguments: the package and the version number. Autoconf tries to derive a tarball name from the package name, which should work for most but not all package names.

This can be avoided by passing the no-define option see List of Automake options :. Other emacsen can cause this test to hang some, like old versions of MicroEmacs, start up in interactive mode, requiring C-x C-c to exit, which is hardly obvious for a non-emacs user. In most cases, however, you should be able to use C-c to kill the test.

You must use this macro when you use the archiver in your project, if you want support for unusual archivers such as Microsoft lib. The content of the optional argument is executed if the archiver interface is not recognized; the default action is to abort configure with an error message.

Use this macro when you have assembly code in your project. This is an obsolescent macro that checks that the C compiler supports the -c and -o options together. Note that, since Automake 1. HP-UX 10 is one such system. This macro finds the gcj program or causes an error. This macro will abort configure if no Unified Parallel C compiler is found.

Find a maintainer tool program and define the name environment variable with its location. If program is not detected, then name will instead invoke the missing script, in order to give useful advice to the user about the missing maintainer tool.

Control the machinery for less verbose build output see How Automake can help in silencing Make. Add support for the Dmalloc package. Although using some of the following macros was required in past releases, you should not use any of them in new code. All these macros will be removed in the next major Automake version ; if you are still using them, running autoupdate should adjust your configure.

Do it NOW! From Automake 1. The following macros are private macros you should not call directly. They are called by the other public macros when appropriate. Do not rely on them, as they might be changed in a future version. Consider them as implementation details; or better, do not consider them at all: skip this section! They are called automatically by Automake when required, and there should be no need to invoke them manually. This macro is automatically invoked when needed; there should be no need to invoke it manually.

This is used to find a version of install that can be used to strip a program at installation time. This macro is automatically included when required. This checks to make sure that a file created in the build directory is newer than a file in the source directory. This can fail on systems where the clock is set incorrectly. For simple projects that distribute all files in the same directory it is enough to have a single Makefile.

In larger projects, it is common to organize files in different directories, in a tree. Because this approach is very widespread, Automake offers built-in support for it. In packages using make recursion, the top level Makefile. The rules for many targets e. This allows inclusion of libraries from packages that do not use Automake such as gettext ; see also Third-Party Makefile s.

In packages that use subdirectories, the top-level Makefile. For instance, here is the Makefile. Automake can be used to construct packages of arbitrary depth this way.

By default, Automake generates Makefiles that work depth-first in postfix order: the subdirectories are built before the current directory. However, it is possible to change this ordering. It is customary to arrange test directories to be built after everything else since they are meant to test what has been constructed.

In addition to the built-in recursive targets defined by Automake all , check , etc. Automake generates rules to handle the recursion for such targets; and the developer can define real actions for them by defining corresponding -local targets. There are two ways to set up a project like this. Using Automake conditionals is the preferred solution. It must be defined manually; Automake will never guess a directory is to be built.

As we will see in the next two sections, it is possible to define it conditionally so that some directory will be omitted from the build. Here by configuring we mean creating the Makefile it might also involve running a nested configure script: this is a costly operation that explains why people want to do it conditionally, but only the Makefile is relevant to the discussion.

The above examples all assume that every Makefile is created, even in directories that are not going to be built. Building packages that do not configure every subdirectory is a tricky business, and we do not recommend it to the novice as it is easy to produce an incomplete tarball by mistake. We will not discuss this topic in depth here, yet for the adventurous here are a few rules to remember.

Think of the former as a way to tell which directories listed in the latter should be built. That is, the Makefile must exist or the recursive make rules will not be able to process the directory. This is so the cleaning rules remove the generated Makefile s. In a few packages, unconfigured directories are not even expected to be distributed. Although these packages do not require the aforementioned extra arrangements, there is another pitfall. Consequently automake cannot be run on such a distribution when one directory has been omitted.

Automake is intended to have sufficient cross-directory support to enable you to write a single Makefile. If it seems to be lacking, please report the issue as usual. By default an installable file specified in a subdirectory will have its directory name stripped before installation. For instance, the last example could be rewritten as follows:.

The install target depends on both of these targets. These rules can do almost anything; care is required. Automake also supports two install hooks, install-exec-hook and install-data-hook. What's the best, most portable way to install whole directory in install-data-local? The find command has a printf output option which might be easier to understand then piping to sed. Show 1 more comment. Three minor suggestions, unrelated to the actual question. Also you can probably extract in verbose mode in order to create your manifest at the same time avoiding the two decompressions of the big archive.

Finally the use of all those long options e. I always thought that using long options in scripts made the scripts easier to read, but portability is better. Jack Kelly Jack Kelly Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown.