Build config: extended syntax

For convenience, ZenMake supports some syntax extensions in buildconf files.

Syntactic sugar

There are some syntactic sugar constructions that can be used to make a buildconf a little shorter.

configure

It can be used as a replacement for configure task param.

For example you have (in YAML format):

tasks:
  util:
    features : cshlib
    source   : shlib/**/*.c
    configure:
      - do: check-headers
        names : stdio.h

  test:
    features : cprogram
    source   : prog/**/*.c
    use      : util
    configure:
      - do: check-headers
        names : stdio.h

So it can be converting into this:

tasks:
  util:
    features : cshlib
    source   : shlib/**/*.c

  test:
    features : cprogram
    source   : prog/**/*.c
    use      : util

configure:
  - do: check-headers
    names : stdio.h

The configure above is the same as following construction:

byfilter:
  - for: all
    set:
      configure:
        - do: check-headers
          names : stdio.h

In addition to regular arguments for configure task param you can use for/not-for/if in the same way as in the byfilter.

Example:

tasks:
  # .. skipped

configure:
  - do: check-headers
    names : stdio.h
    not-for: { task: mytask }

install

Like as previous configure this can be used as a replacement for install-files task param.

Example:

tasks:
  # .. skipped

install:
  - for: { task: gui }
    src: 'some/src/path/ui.res'
    dst: '$(prefix)/share/$(prjname)'

Substitutions

There are two types of substitutions in ZenMake: bash-like variables with ability to use system environment variables and built-in variables.

Bash-like variables

ZenMake supports substitution variables with syntax similar to syntax of bash variables.

Both $VAR and ${VAR} syntax are supported. These variables can be used in any buildconf parameter value of string/text type.

in YAML format:

param: '${VAR}/some-string'

in Python format:

'param' : '${VAR}/some-string'

ZenMake looks such variables in environment variables at first and then in the buildconf file. You can use a $$ (double-dollar sign) to prevent use of environment variables.

Example in YAML format:

# set 'fragment' variable
fragment: |
  program
  end program

# set 'GCC_BASE_FLAGS' variable
GCC_BASE_FLAGS: -std=f2018 -Wall

tasks:

# ... skipped values

  test:
    features : fcprogram
    source   : src/calculator.f90 src/main.f90
    includes : src/inc
    use      : staticlib sharedlib
    configure:
      - do: check-code
        text: $$fragment # <-- substitution without env
        label: fragment

buildtypes:
  # GCC_BASE_FLAGS can be overwritten by environment variable with the same name
  debug  : { fcflags: $GCC_BASE_FLAGS -O0 }
  release: { fcflags: $GCC_BASE_FLAGS -O2 }
  default: debug

Note

These substitution variables inherit values from parent buildconf in subdirs.

Also values for such variables can be set by some configuration actions. For example see var in configuration action find-program. But in this case these values are not visible everywhere.

For YAML format there are some constraints with ${VAR} form due to YAML specification:

debug  : { fcflags: $GCC_BASE_FLAGS -O0 }     # works
debug  : { fcflags: "$GCC_BASE_FLAGS -O0" }   # works
debug  : { fcflags: ${GCC_BASE_FLAGS} -O0 }   # doesn't work
debug  : { fcflags: "${GCC_BASE_FLAGS} -O0" } # works
debug  :
  fcflags: ${GCC_BASE_FLAGS} -O0              # works

Built-in variables

ZenMake has some built-in variables that can be used as substitutions. To avoid possible conflicts with environment and bash-like variables the syntax of substitutions is a little bit different in this case:

in YAML format:

param: '$(var)/some-string'

in Python format:

'param' : '$(var)/some-string'

List of built-in variables:

prjname

Name of the current project. It can be changed via name from here.

topdir

Absolute path of startdir of the top-level buildconf file. Usually it is root directory of the current project.

buildrootdir

Absolute path of buildroot.

buildtypedir

Absolute path of current buildtype directory. It is current value of buildroot plus current buildtype.

prefix

The installation prefix. It is a directory that is prepended onto all install directories and it defaults to /usr/local on UNIX and C:/Program Files/$(prjname) on Windows. It can be changed via environment variable PREFIX or via --prefix on the command line.

execprefix

The installation prefix for machine-specific files. In most cases it is the same as the $(prefix) variable. It was introduced mostly for compatibility with GNU standard: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html. It can be changed via environment variable EXEC_PREFIX or via --execprefix on the command line.

bindir

The directory for installing executable programs that users can run. It defaults to $(exeprefix)/bin on UNIX and $(exeprefix) on Windows. It can be changed via environment variable BINDIR or via --bindir on the command line.

sbindir

The directory for installing executable programs that can be run, but are only generally useful to system administrators. It defaults to $(exeprefix)/sbin on UNIX and $(exeprefix) on Windows. It can be changed via environment variable SBINDIR or via --sbindir on the command line.

libexecdir

The directory for installing executable programs to be run by other programs rather than by users. It defaults to $(exeprefix)/libexec on UNIX and $(exeprefix) on Windows. It can be changed via environment variable LIBEXECDIR or via --libexecdir on the command line.

libdir

The installation directory for object files and libraries of object code. It defaults to $(exeprefix)/lib or $(exeprefix)/lib64 on UNIX and $(exeprefix) on Windows. On Debian/Ubuntu, it may be $(exeprefix)/lib/<multiarch-tuple>. It can be changed via environment variable LIBDIR or via --libdir on the command line.

sysconfdir

The installation directory for read-only single-machine data. It defaults to $(prefix)/etc on UNIX and $(prefix) on Windows. It can be changed via environment variable SYSCONFDIR or via --sysconfdir on the command line.

sharedstatedir

The installation directory for modifiable architecture-independent data. It defaults to /var/lib on UNIX and $(prefix) on Windows. It can be changed via environment variable SHAREDSTATEDIR or via --sharedstatedir on the command line.

localstatedir

The installation directory for modifiable single-machine data. It defaults to $(prefix)/var. It can be changed via environment variable LOCALSTATEDIR or via --localstatedir on the command line.

includedir

The installation directory for C header files. It defaults to $(prefix)/include. It can be changed via environment variable INCLUDEDIR or via --includedir on the command line.

datarootdir

The installation root directory for read-only architecture-independent data. It defaults to $(prefix)/share on UNIX and $(prefix) on Windows. It can be changed via environment variable DATAROOTDIR or via --datarootdir on the command line.

datadir

The installation directory for read-only architecture-independent data. It defaults to $(datarootdir). It can be changed via environment variable DATADIR or via --datadir on the command line.

appdatadir

The installation directory for read-only architecture-independent application data. It defaults to $(datarootdir)/$(prjname) on UNIX and $(datarootdir) on Windows. It can be changed via environment variable APPDATADIR or via --appdatadir on the command line.

docdir

The installation directory for documentation. It defaults to $(datarootdir)/doc/$(prjname) on UNIX and $(datarootdir)/doc on Windows. It can be changed via environment variable DOCDIR or via --docdir on the command line.

mandir

The installation directory for man documentation. It defaults to $(datarootdir)/man. It can be changed via environment variable MANDIR or via --mandir on the command line.

infodir

The installation directory for info documentation. It defaults to $(datarootdir)/info. It can be changed via environment variable INFODIR or via --infodir on the command line.

localedir

The installation directory for locale-dependent data. It defaults to $(datarootdir)/locale. It can be changed via environment variable LOCALEDIR or via --localedir on the command line.

In some cases some extra variables are provided. For example, variables src and tgt are provided for the cmd in the task parameter run.

Built-in variables cannot be used in buildconf parameters which are used to determine values of that built-in variables. These parameters are: