Setting up MacPorts libsolv branch and Testing libsolv search
Clemens Lang
cal at macports.org
Tue Jun 23 01:24:03 PDT 2015
Hi,
----- On 23 Jun, 2015, at 01:07, Joshua Root jmr at macports.org wrote:
> How are you planning on handling variants? It seems to me that the only
> tractable approach would be to evaluate the package universe lazily,
> running mportopen to get data from portfiles only when it is required.
I've been in contact with the developer of libsolv about that and my
current approach would be to represent every variant separately in the
package universe, e.g. a port A with the variants var1, var2, var3 with a
conflict between var2 and var3 and an additional dependency on C in var1
would become
portA+0 (i.e. without variants)
Provides: portA
portA+var1
Provides: portA
Requires: portC
portA+var2
Provides: portA
Conflicts portA+var3
portA+var3
Provides: portA
Conflicts: portA+var2
Then, after solving the dependency problem, post-processing would fold the
results back into a single port name with multiple variant selections.
This would require accurate dependency information for variants. I think that
can be achieved by instrumenting the various depends_*-* operations and
storing their effect during PortIndex generation. Of course that also means
that stuff like
variant foo {
if {[run arbitrary code here]} {
depends_lib-append port:foo
}
}
will no longer work, but I'd argue that this should not be legal anyway. We
only need to be able to switch the default variant programmatically, and we'll
find a way to do that.
--
Clemens Lang
More information about the macports-dev
mailing list