blob: 5d1015d9d6652d132e58570c776736cb335855be (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
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.
|
