Dependencies

ZenMake supports several types of dependencies for build projects:

System libraries

System libraries can be specified by using the config parameter libs. Usually you don’t need to set paths to system libraries but you can set them using the config parameter libpath.

Local libraries

Local libraries are libraries from your project. Use the config parameter use to specify such dependencies.

Sub buildconfs

You can organize building of your project by using more than one buildconf file in some sub directories of your project. In this case ZenMake merges parameters from all such buildconf files. But you must specify these sub directories by using the config parameter subdirs.

Parameters in the sub buildconf can always overwrite matching parameters from the parent buildconf. But some parameters are not changed.

These parameters can be set only in the the top-level buildconf:

buildroot, realbuildroot, project, general, cliopts

Also default build type can be set only in the top-level buildconf.

These parameters are always used without merging with parent buildconfs:

startdir, subdirs, tasks

ZenMake doesn’t merge your own variables in your buildconf files if you use some of them. Other variables are merged including byfilter. But build tasks in the byfilter which are not from the current buildconf are ignored excepting explicit specified ones.

Some examples can be found in the directory ‘subdirs’ in the repository here.

External dependencies

A few basic types of external dependencies can be used:

• Depending on other ZenMake projects
• Depending on non-ZenMake projects

See full description of buildconf parameters for external dependencies here.

ZenMake projects

Configuration for this type of dependency is simple in most cases: you set up the config variable edeps with the rootdir and the export-includes (if it’s necessary) and then specify this dependency in use, using existing task names from dependency buildconf.

Example in YAML format:

edeps:
    zmdep:
        rootdir: ../zmdep
        export-includes: ../zmdep

tasks:
    myutil:
        features : cxxshlib
        source   : 'shlib/**/*.cpp'
        # Names 'calclib' and 'printlib' are existing tasks in 'zmdep' project
        use: zmdep:calclib zmdep:printlib

Example in Python format:

edeps = {
    'zmdep' : {
        'rootdir': '../zmdep',
        'export-includes' : '../zmdep',
    },
}

tasks = {
    'myutil' : {
        'features' : 'cxxshlib',
        'source'   : 'shlib/**/*.cpp',
        # Names 'calclib' and 'printlib' are existing tasks in 'zmdep' project
        'use' : 'zmdep:calclib zmdep:printlib',
    },
}

Additionally, in some cases, the parameter buildtypes-map can be useful.

Also it’s recommended to use always the same version of ZenMake for all such projects. Otherwise there are some compatible problems can be occured.

Note

Command line options --force-edeps and --buildtype for current project will affect rules for its external dependencies while all other command line options will be ignored. You can use environment variables to have effect on all external dependencies. And, of course, you can set up each buildconf in the dependencies to have desirable behavior.

Non-ZenMake projects

You can use external dependencies from some other build systems but in this case you need to set up more parameters in the config variable edeps. Full description of these parameters can be found here. Only one parameter buildtypes-map is not used for such dependencies.

If it’s necessary to set up different targets for different buildtypes you can use selectable parameters in build tasks of your ZenMake project.

Example in Python format:

foolibdir = '../foo-lib'

edeps = {
    'foo-lib-d' : {
        'rootdir': foolibdir,
        'export-includes' : foolibdir,
        'targets': {
            'shared-lib' : {
                'dir' : foolibdir + '/_build_/debug',
                'type': 'shlib',
                'name': 'fooutil',
            },
        },
        'rules' : {
            'build' : 'make debug',
        },
    },
    'foo-lib-r' : {
        'rootdir': foolibdir,
        'export-includes' : foolibdir,
        'targets': {
            'shared-lib' : {
                'dir' : foolibdir + '/_build_/release',
                'type': 'shlib',
                'name': 'fooutil',
            },
        },
        'rules' : {
            'build' : 'make release',
        },
    },
}

tasks = {
    'util' : {
        'features' : 'cxxshlib',
        'source'   : 'shlib/**/*.cpp',
    },
    'program' : {
        'features' : 'cxxprogram',
        'source'   : 'prog/**/*.cpp',
        'use.select' : {
            'debug'   : 'util foo-lib-d:shared-lib',
            'release' : 'util foo-lib-r:shared-lib',
        },
    },
}

Common notes

You can use command line option -E/--force-edeps to run rules for external dependencies without checking triggers.

Some examples can be found in the directory ‘external-deps’ in the repository here.