Next: Writing Autoconf Macros, Previous: Existing Tests, Up: Tests in configure.ac [Contents][Index]
If the existing feature tests don’t do something you need, you have to write new ones. These macros are the building blocks. They provide ways for other macros to check whether various kinds of features are available and report the results.
This section contains some suggestions and some of the reasons why the existing tests are written the way they are. You can also learn a lot about how to write Autoconf tests by looking at the existing ones. If something goes wrong in one or more of the Autoconf tests, this information can help you understand the assumptions behind them, which might help you figure out how to best solve the problem.
These macros check the output of the compiler system of the current language (see Language Choice). They do not cache the results of their tests for future use (see Caching Results), because they don’t know enough about the information they are checking for to generate a cache variable name. They also do not print any messages, for the same reason. The checks for particular kinds of features call these macros and do cache their results and print messages about what they’re checking for.
When you write a feature test that could be applicable to more than one software package, the best thing to do is encapsulate it in a new macro. See Writing Autoconf Macros for how to do that.
• Language Choice | Selecting which language to use for testing | |
• Writing Test Programs | Forging source files for compilers | |
• Running the Preprocessor | Detecting preprocessor symbols | |
• Running the Compiler | Detecting language or header features | |
• Running the Linker | Detecting library features | |
• Runtime | Testing for runtime features | |
• Systemology | A zoology of operating systems | |
• Multiple Cases | Tests for several possible values |
Next: Writing Autoconf Macros, Previous: Existing Tests, Up: Tests in configure.ac [Contents][Index]