Similar to Ac_define, but there are three shell replacements for variable and value (each substitution is done only once): Variable extension (' $ '), command substitution (' "), and backslash (' \ '). Single and double quotes in values have no special meaning. Use this macro instead of Ac_define when variable or value is a shell variable. For example:
Because of the grammatical specificity of the Bourne shell, do not use semicolons to separate calls to Ac_define or ac_define_unquoted and other macro calls or shell code; This will cause syntax errors in the final configure script. You can use either a space or a wrapping line. That's it:
Setting output variables
One way to record test results is to set the output variable, which is a shell variable, and its value will be replaced with the Configure output file. The following two macros create new output variables. For a list of output variables that are always available, see predefined output variables.
Macro: AC_SUBST (variable)
Create an output variable from a shell variable. Let Ac_output replace the variable variable with the output file (usually one or more ' Makefile '). This means that ac_output will replace the ' @variable @ ' instance in the input file with the value of the shell variable variable when the call Ac_output. The variable value cannot contain new rows.
Macro: Ac_subst_file (variable)
Another way to create an output variable from a shell variable. Let Ac_output insert the contents of the file (without replacing) of the filename given by the shell variable variable into the output file. This means that ac_output will replace the ' @variable @ ' instance in the input file with the contents of the file specified by the value of the shell variable variable when the ac_output is invoked, in the output file (such as ' makefile.in '). If no files can be inserted, set the variable to '/dev/null '.
This macro is used to insert ' Makefile ' fragments that contain special dependencies or other make directives prepared for a particular host or target machine ' Makefile '. For example, ' configure.in ' can contain:
Cached results
To avoid repeatedly checking the same feature in various configure scripts (or running the same script repeatedly), configure stores many of its results in a cached file. If the Configure script runs, it finds the cached file, and it reads the results from the previous run and does not rerun the checks. Therefore, configure will be much faster than running all the checks every time.
Macros: Ac_cache_val (Cache-id, commands-to-set-it)
Verify that the results of the check specified by Cache-id are available. If the result of the check is in a read-in cache file, and configure does not call '--quiet ' or '--silent ', a message is printed to indicate that the result has been cached, otherwise the shell command commands-to-set-it is run. These commands should not have side effects, except for setting variable Cache-id. In particular, they should not call Ac_define, followed by the code after the call to Ac_cache_val should invoke ac_define based on the cached value. In addition, they should not print any messages, such as using ac_msg_checking, and should print before calling Ac_cache_val so that the message is printed regardless of whether the test results are retrieved from the cache or are determined by running the shell command. If you run the shell command to determine the value, the value is stored in the cached file before configure creates its output file. For information on how to select the name of the Cache-id variable, see cache variable names.
Macros: Ac_cache_check (message, Cache-id, commands)
This is a ac_cache_val version that deals with printing messages in more detail. Benhong provides a handy abbreviation for the most common applications of these macros. It invokes ac_msg_checking for the message, then calls Ac_cache_val for parameters Cache-id and commands, and finally calls Cache-id as arguments.
Macro: Ac_cache_load
Loads a value from a cached file that already exists, and creates a new cached file if no cached file is found. This macro is invoked automatically by Ac_init.
Macro: Ac_cache_save
Flushes all cached values to the cached file. This macro is invoked automatically by Ac_output, but it is useful to call Ac_cache_save at the configure.in key point. If the configuration script fails Midway (abort), these key points can still cache a subset of the results.
Cache variable Name
The name of the cached variable should conform to the following format:
For example, ' Ac_cv_header_stat_broken ' or ' ac_cv_prog_gcc_traditional '. The various parts of the variable name are:
Package-prefix
The initials of your package or organization, in addition to using lowercase letters for convenience, the same prefix you used as the beginning of a local autoconf macro. For the cached value that is used by the published autoconf macro, it is ' AC '.
_cv_
Indicates that this shell variable is a cached value.
Value-type
Conventions on caching value classes to generate a reasonable naming system. The values used in autoconf are listed in the macro name.
Specific-value
Indicates the member of this test that is applied to the cached value class. For example, that function (' alloca '), the program (' GCC '), or the output variable (' INSTALL ').
Additional-options
Give any special behavior that applies to a particular member of this test. For example, ' broken ' or ' set '. If it doesn't work, this part of the name may be ignored.
The value given to a cached variable cannot contain a new row. Usually, they will be Boolean (' yes ' or ' no ') or filename or function name; So, this is not an important limitation.
Caching files
A cached file is a shell script that caches the results of a configuration test on a system so that it can be shared between the configuration script and the configured run. It's no use for other systems. If its contents become invalid for some reason, the user can delete or edit it.
By default, configure "./config.cache" as the cached file, and if it does not exist, create it. Configure accepts the option '--cache-file=file ' to use a different cache file; This is what configure does when it calls configure scripts in subdirectories. For information on using macro ac_config_subdirs to configure in subdirectories, see Configuring additional packages in subdirectories.
Giving '--cache-file=/dev/null ' closes the cache, which is provided for debugging configure. The option '--recheck ' is given only when calling ' Config.status ', which causes it to rerun the Configure before it notices the cached file. If you anticipate a long debugging period, you can also turn off loading and storage of configure scripts by redefining the cached macros at the beginning of ' configure.in ':
It is an error to attempt to publish a cached file for a specific system type. There are too many space to cause errors and too much management overhead to maintain them. For any feature that cannot be automatically guessed, you should use a method of standardizing system types and connection files (see manual configuration).
In a particular system, the cached file accumulates gradually when someone runs the Configure script, and the cached file does not exist at the beginning. Running configure combines the new cached results with the existing cache files. To make it work transparently, the site initialization script can specify a site-wide (site-wide) cache file to replace the default cached file, as long as the same C compiler is used every time. (see Set local default values).
Caching at several key points may be useful if your configuration script, or a macro call in configure.in, occasionally results in a failure of the configuration process. This reduces the time to rerun the Configure script when there is a chance of correcting the error that caused the last run.
Print messages
Configure scripts need to provide several kinds of information for the users who run them. The following macros print messages in the appropriate way for each information. All macro parameters should be enclosed in double quotes in the shell so that the shell can replace them with variable and inverted quotes. You can enclose messages in M4 reference characters to print messages that contain parentheses:
Ac_msg_result ([Never mind, I found the BASIC compiler])
These macros are encapsulated in the shell command Echo. Configure should rarely need to run echo directly to print messages for the user. Using these macros makes it easy to modify how each message is printed and when it is printed, which only needs to be done with the definition of the macro, and all calls will change automatically.
Macro: ac_msg_checking (feature-description)
Informs the user that configure is checking for specific features. This macro prints a ' checking ' to start with ' ... ' The message that ends with no new lines. It must follow a call to Ac_msg_result to print the results of the check and the new line. Feature-description should be something like ' whether the Fortran compiler accepts C + + comments ' or ' for c89 '.
If the run configure gives the option '--quiet ' or option '--silent ', the macro does not print anything.
Macro: Ac_msg_result (result-description)
Inform the user of the results of the test. Result-description almost always checks the value of the cached variable, typically the value is ' yes ', ' no ' or filename. This macro should be called after ac_msg_checking, and result-description should complete the message printed by ac_msg_checking.
If the run configure gives the option '--quiet ' or option '--silent ', the macro does not print anything.
Macro: Ac_msg_error (error-description)
Inform the user of an error that makes configure impossible to complete. Benhong prints an error message in the standard error output and exits configure in a non-0 state. Error-description should be something like ' invalid value $HOME for \ $HOME '.
Macro: Ac_msg_warn (problem-description)
Inform the Configure user of any possible problems. Benhong print messages in standard error output; Configure continue to run backwards, so the macros that invoke Ac_msg_warn should provide a default (backup) behavior for the situation they are warning. Problem-description should be something like ' ln-s seems to make hard links '.
The following two macros are obsolete alternative versions of ac_msg_checking and Ac_msg_result.
Macro: ac_checking (feature-description)
In addition to printing new lines after feature-description, Benhong is the same as ac_msg_checking. It is primarily used to print a description of the overall purpose of a set of feature tests, such as:
Ac_checking (if stack overflow is detectable)
Macro: Ac_verbose (result-description)
The Benhong is the same as Ac_msg_result, except that it should be called after the ac_checking, rather than after ac_msg_checking, which prints a tab first before printing the message. It's out of date.
Writing macros
When you write a feature test that can be used with multiple packages, it's best to encapsulate it with a new macro. Here are some requirements (instructions) and guidance (guidelines) for writing autoconf macros.
Macro definition
The autoconf macro is defined with the macro Ac_defun, which is similar to the M4 built-in define macro. In addition to defining a macro, Ac_defun adds some code to restrict the order in which the macros are called. (See the first macro).
A autoconf macro is defined as follows:
Ac_defun (Macro-name, [macro-body])
The square brackets here do not represent optional text: they should appear in the macro definition as they are, to avoid macro expansion issues (see references). You can use ' $ ', ' $ ', and so on to access any parameters passed to the macro.
To use the M4 annotation, use the M4 built-in DNL, which causes M4 to discard all subsequent text in the bank. Because all output is canceled before Ac_init is invoked, it is not needed between the macro definitions in ' acsite.m4 ' and ' aclocal.m4 '.
For more complete information on writing M4 macros, see ' How to define a new macro ' in the GNU M4.
Macro Name
All autoconf macros begin with ' ac_ ' to prevent accidental conflicts with other text. All of the shell variables that they use for internal purposes are almost entirely of lowercase letters, with names that begin with ' ac_ '. To make sure your macros don't conflict with current or future autoconf macros, you should prefix your own macro names with any shell variables that they need to use for some reason. It may be the beginning of your name, or the initials of your organization or package name.
The name of most autoconf macros obeys a kind of naming convention that indicates a feature check. A macro name consists of several words, separated by an underscore, which can be the most common or the most specific. Their cached variable names are subject to the same conventions. (For more information about them, see caching variable names).
The first word after ' ac_ ' usually gives the category of the feature being tested. The following are the categories that Autoconf uses for special test macros, which are macros that you will most likely write. Their full lowercase form is also used for caching variables. Use them where possible; if not, invent a category of your own.
C
C language built-in features.
Decl
A declaration of a C variable in a header file.
FUNC
The functions in the library.
GROUP
The UNIX group owner of the file.
HEADER
Header file.
Lib
C library.
PATH
The full pathname to the file, including the program.
PROG
The base name (base name) of the program.
STRUCT
The definition of the C structure in the header file.
SYS
Operating system characteristics.
TYPE
C built-in or declarative type.
Var
c variables in the library.
After the category is the name of the specific tested feature. All other words in the macro name indicate the special aspects of the feature. For example, Ac_func_utime_null checks the behavior of the Utime function when it is invoked with a null pointer.
The name of a macro that is an internal subroutine for another macro should begin with the name of the macro that uses it, followed by one or more words that describe what the internal macro did. For example, ac_path_x has internal macros AC_PATH_X_XMKMF and Ac_path_x_direct.
Reference
Macros called by other macros are evaluated several times by M4, and each evaluation may require a layer of quotation marks to prevent unnecessary extensions to macros or M4 built-in macros, such as ' Define ' and ' $ '. Quotation marks also need to appear in macro parameters that contain commas, because commas separate arguments from arguments. Also, it's a good idea to draw all the macro parameters that contain new lines and invoke other macros.
Autoconf the reference character of the M4 from the default ' and ' to ' [' and '] ', because many macros use ' and ', which is inconvenient. However, in a few cases, macros need to use square brackets (usually in the C program text or in regular expressions). In these cases, they use the M4 built-in command Changequote temporarily change the reference character to ' << ' and ' >> '. (Sometimes, if they don't need to refer to anything, they simply close the reference by setting the reference character to an empty string.) The following is an example:
When you create a configure script with a newly-written macro, verify it carefully to see if you need to add more quotes to your macros. If one or more words disappear in the M4 output, you need more quotes. When you are unsure, use quotes.
However, there is also the possibility of placing too many layers of quotes. If this happens, the results of the Configure script will contain the macros that are not expanded. The program autoconf checks this problem by executing ' grep ac_ configure '.
dependencies between macros
To work correctly, some autoconf macros require other macros to be invoked before they are invoked. Autoconf provides a way to ensure that a macro has been invoked when needed, and a way to give a warning when a macro might cause an incorrect action.
The first macro
The macros you write may need to be calculated using other macros that were previously computed. For example, Ac_decl_yytext wants to verify the output of flex or lex, so it requires that Ac_prog_lex be called first to set the shell variable Lex.
Better than forcing a user to track macros before, you can use the macro Ac_require to automate this task. Ac_require can ensure that macros are invoked only once, and only once, when needed.
Macro: Ac_require (macro-name)
If the M4 macro Macro-name is not yet invoked, it is called (without any arguments). Make sure the macro-name is coming with square brackets. Macro-name must have already been defined with Ac_defun, or include a call to Ac_provide to indicate that it has been invoked.
One way to replace Ac_defun is to use define and invoke Ac_provide. Because this technique does not prevent nested messages, it is already obsolete.
Macro: Ac_provide (this-macro-name)
Record the fact that This-macro-name has been invoked. This-macro-name should be the name of the macro that calls Ac_provide. A simple way to get it is to get it from the M4 built-in variable $, like this:
Ac_provide ([$])
Order of recommendations
When some macros are invoked, a macro needs to run before another macro, but they do not require another macro to be invoked. For example, you should invoke a macro that modifies the C compiler behavior before any macros running the C compiler. Many of these dependencies are given in the documentation.
When macros in the ' configure.in ' file violate such dependencies, AUTOCONF provides a macro ac_before to warn the user. The warning appears when you create a configure from ' configure.in ', not when you run configure. For example, Ac_prog_cpp checks whether the C compiler can run a C preprocessor in the case of ' e '. It should therefore be invoked after any change to the macro that will be used for the C compiler. So AC_PROG_CC contains:
Ac_before ([$], [ac_prog_cpp]) DNL
If Ac_prog_cpp is invoked when AC_PROG_CC is invoked, it warns the user.
Macros: Ac_before (this-macro-name, Called-macro-name)
If Called-macro-name has already been invoked, let M4 print a warning message on the standard error output. This-macro-name should be the name of the macro that calls Ac_before. Macro-name must have already been defined with Ac_defun, or include a call to Ac_provide to indicate that it has been invoked.
Obsolete macros
Configuration and porting techniques have evolved over the years. A better solution is usually proposed for a particular problem, or the same approach (Ad-hoc approaches) has been systematized. The result is that some macros are now considered obsolete; they can still work, but they are no longer considered the best choice. AUTOCONF provides macro ac_obsolete that when users use outdated macros, they warn users when they generate configure scripts to encourage them to keep up with the trend. One invocation instance is:
Ac_obsolete ([$], [; use Ac_check_headers (unistd.h) instead]) DNL
Macros: Ac_obsolete (this-macro-name [, suggestion])
Let M4 print a message on the standard error output to warn that this-macro-name is obsolete and give the file name and line number of the call to the obsolete macro. This-macro-name should be the name of the macro that calls Ac_obsolete. If suggestion is given, print it at the end of the warning message; For example, it can suggest a macro instead of this-macro-name.
Manual configuration
There are several features that cannot be guessed automatically by running the test program. For example, the details of the destination file format, or special options that need to be passed to the compiler or connector. You can use similar methods (Ad-hoc means) to check for such features, such as letting configure check the output of uname programs, or looking for libraries that only appear on a particular system. However, Autoconf provides a unifying tool for dealing with unpredictable features.
Specifying the type of system
Similar to other GNU configure scripts, autoconf generated configure scripts can be determined according to the canonical name of the system type (canonical name), which is in the form of the canonical system name:
Cpu-company-system
Configure can usually guess the canonical name of the system type it is running. To do this, it runs a script called Config.guess that uses the uname or predefined C preprocessor notation to infer the canonical name of the system type.
In addition, users can specify the system type by passing command-line arguments to configure. This must be done at the time of the cross compilation. In most complex cases of cross compilation, there are three types of systems involved. The options for specifying them are:
--build=build-type
The type of system (rarely used) to configure and compile the package;
--host=host-type
The type of system the package will run;
--target=target-type
The system type of the code that will be generated by any compiler tool in the package.
If the user gives configure a non option parameter, if the user does not explicitly use the option, it represents the host type, the target type, and the creation system type as the default. If the host type is given without the target type and creation type, the target type and the creation type are set to the host type. If you are compiling, you still have to give the name of the crossover tool (Cross-tools) You use in the Configure command line, especially the C compiler. For example
CC=M68K-COFF-GCC Configure--target=m68k-coff
Configure can identify short aliases for many system types; For example, you can give ' decstation ' instead of ' mips-dec-ultrix4.2 ' on the command line. Configure runs a script called Config.sub to normalize the system type alias.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
