QtCurve-extra: universal variant fails

[ryandesign (Ryan Carsten Schmidt)]

Attempting to install QtCurve-extra with the universal variant fails:

--->  Configuring QtCurve-extra for architecture x86_64
Error: Failed to configure QtCurve-extra: error copying "/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk_kde_qtcurve/QtCurve-extra/work/QtCurve-1.9.0": no such file or directory

QtCurve-extra declares supported_archs noarch so it shouldn't even have a universal variant. The reason it does it that the muniversal 1.0 portgroup is being included unconditionally, into all subports. It should not be included in the QtCurve-extra subport.

[RJVB (René Bertin)]

You're right of course.

But can't this be handled in the muniversal PG? I don't think it will be possible to use supported_archs eq "noarch" to skip declaring the universal variant but something like the patch below should make the variant a noop (it removes the error for QtCurve-extra):

diff --git a/_resources/port1.0/group/muniversal-1.0.tcl b/_resources/port1.0/group/muniversal-1.0.tcl
index 4d2d121a155d00b625086ef429ec3c0e2b7a76fd..d8c0767d5b928f67ca4147f55724628af393ffeb 100644
--- a/_resources/port1.0/group/muniversal-1.0.tcl
+++ b/_resources/port1.0/group/muniversal-1.0.tcl
@@ -129,6 +129,11 @@ merger_target_provides ${org.macports.destroot} destroot
 variant universal {
     global universal_archs_to_use
 
+    if {${supported_archs} eq "noarch"} {
+        ui_info "Port ${subport} is architecture-agnostic"
+        return
+    }
+
     foreach arch ${universal_archs} {
         configure.universal_cflags-delete    -arch ${arch}
         configure.universal_cxxflags-delete  -arch ${arch}

[ryandesign (Ryan Carsten Schmidt)]

The muniversal portgroup currently defines a universal variant when you include it. It also defines procedures and options that relate to that universal variant. If you don't want a universal variant, don't include the portgroup. It's always been as simple as that.

The simplest solution for your portfile is therefore to include the portgroup only if ${subport} ne "${name}-extra".

If you want to change the behavior of the portgroup so that it does not define the universal variant if ${supported_archs} eq "noarch", that would require supported_archs to be declared before the portgroup is included. Portgroups are usually included at the top of the portfile, and in your portfile, you do include the portgroup before setting supported_archs.

Your patch makes the portgroup's universal variant print an error if ${supported_archs} eq noarch. That might be a reasonable safeguard to have in the portgroup, but it does not excuse the portfile from using the portgroup correctly. We don't usually want ports to have variants that do nothing but print an error.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

The simplest solution for your portfile is therefore to include the portgroup only if ${subport} ne "${name}-extra".

Sorry, I see now this is exactly what your patch does. I'll commit that.

[ryandesign (Ryan Carsten Schmidt)]

In 8ff8030668f07b605286be5582e7fc0986ae3fce/macports-ports (master):

QtCurve: Disable universal variant for QtCurve-extra

Closes: #56466

[RJVB (René Bertin)]

Your patch makes the portgroup's universal variant print an error if ${supported_archs} eq noarch. That might be a reasonable safeguard to have in the portgroup

A warning, but yes, that was the intention since apparently it's not possible to do anything else.

But is that really true? I'm guessing that the standard universal variant is defined by "base" after the Portfile has been interpreted, and only if such a variant wasn't already defined? If true, the muniversal PG could use if {[variant_isset universal]} instead of declaring the variant, and set a special state variable. The "base" code could then use that state variable to decide whether to declare the standard universal variant, or an empty variant (= without code) instead.

[ryandesign (Ryan Carsten Schmidt)]

Replying to RJVB:

I'm guessing that the standard universal variant is defined by "base" after the Portfile has been interpreted, and only if such a variant wasn't already defined?

Right. After the entire portfile has been processed by base, if no universal variant was defined by it, and if the port did not disable the universal variant, and if the port supports more than one arch, and if the port does not disable the configure phase, base will add the standard universal variant.

This is different from the muniversal portgroup, which unconditionally adds its universal variant at the moment that the portgroup is included.

If true, the muniversal PG could use if {[variant_isset universal]} instead of declaring the variant, and set a special state variable. The "base" code could then use that state variable to decide whether to declare the standard universal variant, or an empty variant (= without code) instead.

Sorry, I don't understand how that would work.

I'll just say that base should not have knowledge of portgroup-specific information.

It would be nice if the muniversal portgroup went away and its functionality were part of MacPorts base. That would solve the issue we're talking about, but would of course require all ports that use the portgroup to be visited to adapt them to the changes.

[RJVB (René Bertin)]

Sorry, I don't understand how that would work. I'll just say that base should not have knowledge of portgroup-specific information.

See it as the opposite: an additional way for a PG to "base" *not* to define the standard universal variant, but instead only declare it. Concretely, in muniversal-1.0.tcl:

if {[variant_isset universal]} {
   # muniveral variant code
}
base_define_complete_universal_variant   no

somewhere in $prefix/libexec/macports/lib:

if {[tbool base_define_complete_universal_variant]} {
    variant universal description {} {
        # universal variant code
    }
} else {
    # only declare the universal variant so ports can use it
    variant universal description {} {}
}

but would of course require all ports that use the portgroup to be visited to adapt them to the changes.

Or you could use the PortGroup as a transparent means to tell "base" to use the muniversal approach.

[ryandesign (Ryan Carsten Schmidt)]

Base already functions the way you describe: the standard universal variant doesn't contain any code.

browser:macports-base/src/port1.0/portutil.tcl#L2088​

If the portgroup just checks for [variant_isset universal], that's not correct, because a variant can be considered to be set even if the variant does not exist.

Let's stop discussing this in this ticket now. This ticket was about a bug in your port, and we've fixed your port now. If you want to discuss improving the merge-universal code, let's do that elsewhere.