Project description

The project block defines global properties and requirements for the project. Unlike rule files, this block is not purely declarative and there may only be one. While the rule translator is free to move around declarations, the project block defines an order in which requirements are tested. This order is honoured by the translator. 

project 'MakePP' {
   version: '0.1'
   contact: 'makepp@xinutec.org'

   config_header: config.h

   section 'some checks' {
      ...
   }
}

section

Configure time checks are grouped in sections for better readability. Each section is introduced with a message in the configure script output.

library

In a project context, library checks whether a library is installed and a program can be linked against it. 

# GNU Multiprecision Library, can be disabled with --without-gmp,
# if all targets defined in Rules files that link to it are optional.
library gmp {
   symbol: mpz_init
   header: gmp.h
   # You may optionally add a description to each check. This will cause it
   # to appear in the summary at the end of a configure run.
   'Build with GNU Multiprecision Library support'
}

The above library directive defines the following variables:

headers/functions

The headers section can be used to check for additional headers. functions checks whether a list of functions is available. 

headers {
   # Valgrind runtime support
   valgrind/valgrind.h
}
functions {
   # New POSIX signal handling
   sigaction
}

This directive only defines HAVE_ variables in the config header.

arg_enable

This directive adds an option to the resulting configure script. The content of this directive is a descriptive string that is shown when configure is passed --help, followed by more directives that are evaluated if the argument is yes. A default may be given. This default may be yes or no or a backtick-string, which is evaluated at configure time. Thus, the following two are equivalent: 

arg_enable my-sub-package = yes { 'Also build sub-package' }
arg_enable my-sub-package = `echo yes` { 'Also build sub-package' }

This adds the option --enable-my-sub-package and defines the following variables:

options

Instead of a yes/no, you can define your own options. 

arg_enable app = iphone {
   'Build an app for this software. Only one app can be chosen'
   options {
      android => {
         # check for additional libraries
      }
      iphone => {
         warning 'Support for iPhones is unstable.'
      }
      no => {
         # no app is being built
      }
      # optional catch-all option
      _ => {
         error 'No support for the $app phone planned.'
      }
   }
}

The defined variables and macros are the same as with the normal yes/no arg_enable, except that the config header gets one macro per option, which is defined to 1 if that option is selected. Thus, --enable-app=android will define APP_ANDROID to 1.

cflags

The cflags directive tries to compile a simple program with the passed flags and adds them to the named variable or CFLAGS by default. 

# Adds to CFLAGS
cflags {
   -pipe
   -ggdb3
   -pedantic
   -ansi
}
# Adds to HIDDEN_CFLAGS
cflags HIDDEN_CFLAGS {
   -fvisibility=hidden
}

Each of the flags is tested separately in the order listed. The set added to the variable is the subset of flags that work together.

Additional checks

These are checks from autoconf. They translate to AC_ followed by the check name, uppercased.

The following are new: