diff options
| -rw-r--r-- | bpkg/conditional-dependencies | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/bpkg/conditional-dependencies b/bpkg/conditional-dependencies new file mode 100644 index 0000000..5d1015d --- /dev/null +++ b/bpkg/conditional-dependencies @@ -0,0 +1,27 @@ +- Support for conditional dependencies [feature] + +In a nutshell, a package may or may not depend on another package and, in the +worst case scenario, this can be ascertained only during configuration. As a +result, an iterative approach seems like the way to implement this. + +That is, initially, bpkg assumes that a conditional dependency is not +necessary and tries to configure the package without it. It also runs build2 +in the "failed import discovery mode". In this mode build2 outputs to stdout +all the failed imports (maybe all imports?) and exits with non-zero status. +We will also need to limit imports to stage 1 only since we don't want +conditional dependencies to be found as installed [this needs more thinking; +feels like a special case hack at the moment]. + +What if the conditional dependency is already in the configuration? We need +to prevent build2 from using it. Looks like that empty import override idea +will do the trick. + +This process will only discover one conditional dependency per package at a +time which may make the whole thing quite tedious. Not sure what we can do +here since we cannot continue processing a buildfile if we failed to import a +project. Or do we? If we fail to find a build2 project we delegate it to the +rule. So as long as we don't match rules, we are good and can discover all the +failed imports. BTW, an alternative model would be a true import intercept +where we build conditional dependencies as part of the import hook call. The +bad part about this approach is that we cannot show the user the plan for +extra packages we need to build. It is a lot more complex. |