From 305bb45790beeeeb560d5af91c6ec97299a1cf98 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Sun, 25 Sep 2016 04:52:53 +0200 Subject: Add feature: Support for conditional dependencies --- bpkg/conditional-dependencies | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 bpkg/conditional-dependencies 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. -- cgit v1.1