Conflicts and constraints

Configuration options are not completely independent. For example the C library's strtod() and atof() functions rely on the math library package to provide certain functionality. If the math library package is removed then the C library can no longer provide these functions. Each package describes constraints like these in CDL "requires" properties. If a constraint is not satisfied, then the configuration contains a conflict. For any given conflict there can be several resolution options. For example, it would be possible to add the math library package back to the configuration, or to disable the strtod() and atof() functions.

The eCos configuration tools will report any conflicts in the current configuration. If there are any such conflicts then the configuration is usually unsafe and it makes no sense to build and run eCos in such circumstances. In fact, any attempt at building eCos is likely to fail. In exceptional cases it is possible to override this by using e.g. the --ignore-errors qualifier with ecosconfig.

Many constraints are fairly simple in nature, and the configuration tools contain an inference engine which can resolve the associated conflicts automatically. For example, if the math library package is removed then the inference engine can resolve the resulting conflict by disabling the configuration option for strtod() and atof(). All such changes will be reported. Sometimes the inference engine cannot resolve a conflict, for example it is not allowed to override a change that has been made explicitly by the user. Sometimes it will find a solution which does not match the application's requirements.

A typical session involving conflicts would look something like this:

$ ecosconfig new pid

This creates a new configuration with the default template. For most targets this will not result in any conflicts, because the default settings for the various options meet the requirements of the default template.

For some targets there may be conflicts and the inference engine would come into play.

$ ecosconfig remove libm
U CYGSEM_LIBC_STDIO_SCANF_FLOATING_POINT, new inferred value 0
U CYGFUN_LIBC_strtod, new inferred value 0
U CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT, new inferred value 0

ecosconfig reports that this change caused three conflicts, all in the C library. The inference engine was able to resolve all the conflicts and update the relevant configuration options accordingly.

To suppress the inference engine --no-resolve can be used:

$ ecosconfig new pid
$ ecosconfig --no-resolve remove libm
C CYGSEM_LIBC_STDIO_SCANF_FLOATING_POINT, "requires" constraint not satisfied:  CYGPKG_LIBM
C CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT, "requires" constraint not satisfied: CYGPKG_LIBM
C CYGFUN_LIBC_strtod, "requires" constraint not satisfied: CYGPKG_LIBM

Three unresolved conflicts are reported.

The check command can be used to get the current state of the configuration, and the --verbose qualifier will provide additional information:

$ ecosconfig --srcdir /home/bartv/ecc/ecc --verbose check
Target: pid
Template: default
Removed:
 CYGPKG_LIBM
3 conflict(s):
C CYGFUN_LIBC_strtod, "requires" constraint not satisfied: CYGPKG_LIBM
 Possible solution:
    CYGFUN_LIBC_strtod -> 0
    CYGSEM_LIBC_STDIO_SCANF_FLOATING_POINT -> 0
C CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT, "requires" constraint not satisfied: CYGPKG_LIBM
 Possible solution:
    CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT -> 0
C CYGSEM_LIBC_STDIO_SCANF_FLOATING_POINT, "requires" constraint not satisfied:  CYGPKG_LIBM
 Possible solution:
    CYGSEM_LIBC_STDIO_SCANF_FLOATING_POINT -> 0

If the proposed solutions are acceptable, the resolve command can be used to apply them:

$ ecosconfig resolve
U CYGSEM_LIBC_STDIO_SCANF_FLOATING_POINT, new inferred value 0
U CYGFUN_LIBC_strtod, new inferred value 0
U CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT, new inferred value 0

The current configuration is again conflict-free and it is possible to generate a build tree. The --quiet qualifier can be used to suppress the change messages, if desired.

When changing individual configuration options by editing the ecos.ecc file (as described below), the resulting system should be checked and any problems should be resolved. For example, if CYGFUN_LIBC_strtod is explicitly enabled in the savefile:

$ edit ecos.ecc
$ ecosconfig check
Target: pid
Template: default
Removed:
    CYGPKG_LIBM
1 conflict(s):
C CYGFUN_LIBC_strtod, "requires" constraint not satisfied: CYGPKG_LIBM
$ ecosconfig resolve
C CYGFUN_LIBC_strtod, "requires" constraint not satisfied: CYGPKG_LIBM

In this case the inference engine cannot resolve the conflict automatically because that would involve changing a user setting. Any attempt to generate a build tree will fail:

$ ecosconfig --srcdir /home/bartv/ecc/ecc tree
C CYGFUN_LIBC_strtod, "requires" constraint not satisfied: CYGPKG_LIBM
Unable to generate build tree, this configuration still contains conflicts.
Either resolve the conflicts or use --ignore-errors

It is still possible to generate a build tree:

$ ecosconfig --srcdir /home/bartv/ecc/ecc --ignore-errors tree
C CYGFUN_LIBC_strtod, "requires" constraint not satisfied: CYGPKG_LIBM
$ make

In this case eCos will fail to build. In other cases of unresolved conflicts eCos may build, but may not run. In general all conflicts should be resolved by editing the ecos.ecc file, by letting the inference engine make appropriate changes, or by other means, before any attempt is made to build or run eCos.

2017-02-09
Documentation license for this page: Open Publication License