problem building pango+X

[luigi-calori]

It seems that X variant on pango and cairo lead to problems if activated, to reproduce:
spack spec gtkplus
spack -d spec pango+X

[adamjstewart]

This is a known issue. See #2495, #2565, #1552, and #1553 for extensive discussion. The problem is that gtkplus defaults to +X while pango defaults to ~X. Spack isn't currently smart enough to resolve this conflict and crashes. @tgamblin @scheibelp

[citibeth]

I'm closing this issue because it is a duplicate.

[luigi-calori]

I agree it's a duplicate ( sorry, my knowledge of spack internal is not enough for recognize it).
Anyway if possible, I think it would be good to collect also this particular issue along with the other and to provide suggested workarounds.
I need to build these packages, so I tried to fix in #2575
Any hints for better workarounds would be really welcome.

[citibeth]

I think it would be good to collect also this particular issue along with

the other and to provide suggested workarounds. I have suggested Universal Variants as a possible solution to this problem (#2492), but it is still in the discussion stage. See also the discussion in #2546. I'm interested in your opinions on this idea, do you think it would help your problems?

…

On Wed, Dec 14, 2016 at 11:17 AM, Luigi Calori ***@***.***> wrote: I agree it's a duplicate ( sorry, my knowledge of spack internal is not enough for recognize it). Anyway if possible, I think it would be good to collect also this particular issue along with the other and to provide suggested workarounds. I need to build these packages, so I tried to fix in #2575 <#2575> Any hints for better workarounds would be really welcome. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#2574 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB1cd6fan73-AX-0p08soIgBsvgkC-cvks5rIBaWgaJpZM4LMK2l> .

[adamjstewart]

@citibeth Universal variants and/or variant forwarding would definitely solve this issue, but the real problem is that the concretizer isn't smart enough to pick a variant aside from the default. See #2575 for more discussion.

[adamjstewart]

Let me put out a PR for a workaround. It won't be pretty, but I think it will help a lot until the concretizer is fixed.

[luigi-calori]

It seems that one workaround that could work without touching current develop is to explicitly ask for X in gtkplus, without relying to it's default:

spack spec gtkplus+X seem to be correctly concretized, while

spack spec gtkplus produce th error

[citibeth]

@adamjstewart We have two proposals on the table: variant forwarding and universal variants. I think we should seriously consider both in a rational way before going ahead with either.

I looked over #2575 again, and I conclude that variant forwarding and universal variants would provide about the same functionality in the end. But variant forwarding brings up a host of new questions. For example:

1. Suppose A -> B and both of them have the +x variant. What will B see in the three cases of: spack spec A+x, spack spec A~x and spack spec A?

2. We now have non-boolean variants. How do variant forwarding rules from (1) work in those cases?

3. Is it always safe to assume that if A and B both have a variant named the same, that it can be forwarded from A to B? This is not a constraint we've previously placed on our packages; at the very least, we should check to see what variants are named the same between packages and think about those use cases. A more conservative approach would be to require that variants be marked as "forwardable" to have them forwarded. But that brings up the question... do you do the marking in package, A, B or both?

4. What if A -> C -> B; and A and B share a variant that is NOT shared by C? Will the system be able to forward variants across C from A to B?

5. Can you explain more what you mean by "the real problem is that the concretizer isn't smart enough to pick a variant aside from the default"?

Because universal variants don't introduce any new machinery, they don't introduce any of these questions. Someone could try them right now, today just by editing package.py files. I suggest the following immediate courses of action, before investing work on a new Spack feature:

1. We prototype universal variants in a small real-world example (for example this cairo + pango example) and put it up for viewing in a PR. Then we can see how we really feel about universal variants; maybe they are something we think we can live with, maybe they feel totally convoluted, or maybe we like the basic idea but think it needs some fixes.

2. We continue the discussion on variant forwarding, trying to nail down exactly how that feature would work; and try to think through its consequences.

I believe these two tasks, once complete, would give us a better basis for making a final decision.