Opened 12 months ago

Closed 12 months ago

Last modified 12 months ago

#56466 closed defect (fixed)

QtCurve-extra: universal variant fails

Reported by: ryandesign (Ryan Schmidt) Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: RJVB (René Bertin)
Port: QtCurve-extra

Description

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.

Attachments (1)

qtcurve-extra-nouni.diff (440 bytes) - added by RJVB (René Bertin) 12 months ago.

Download all attachments as: .zip

Change History (9)

Changed 12 months ago by RJVB (René Bertin)

Attachment: qtcurve-extra-nouni.diff added

comment:1 Changed 12 months ago by 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}

comment:2 Changed 12 months ago by ryandesign (Ryan 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.

comment:3 in reply to:  2 Changed 12 months ago by ryandesign (Ryan 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.

comment:4 Changed 12 months ago by ryandesign (Ryan Schmidt)

Owner: set to ryandesign
Resolution: fixed
Status: newclosed

In 8ff8030668f07b605286be5582e7fc0986ae3fce/macports-ports (master):

QtCurve: Disable universal variant for QtCurve-extra

Closes: #56466

comment:5 Changed 12 months ago by 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.

comment:6 in reply to:  5 Changed 12 months ago by ryandesign (Ryan 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.

comment:7 Changed 12 months ago by 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.

comment:8 Changed 12 months ago by ryandesign (Ryan 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.

Note: See TracTickets for help on using tickets.