Opened 5 years ago

Last modified 5 years ago

#58229 new defect

base: defining the same variant both in a PG and a port discards description

Reported by: Ionic (Mihai Moldovan) Owned by:
Priority: Low Milestone:
Component: base Version: 2.5.99
Keywords: Cc:
Port:

Description (last modified by Ionic (Mihai Moldovan))

Defining the same variant both in a PG and a port discards its description.

This does not happen if the variant is only defined once - either in a PG xor a port.

Example output from "port variants variantstest" for the minimal testcase:

variantstest has the variants:
   testvariant
   testvariant_PG_only: From PG only
   testvariant_port_only: From port only
(-)universal: Build for multiple architectures

Attachments (2)

_resources_port1.0_group_variantstest-1.0.tcl (115 bytes) - added by Ionic (Mihai Moldovan) 5 years ago.
Minimal PG example.
devel_variantstest_Portfile (342 bytes) - added by Ionic (Mihai Moldovan) 5 years ago.
Minimal port example.

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by Ionic (Mihai Moldovan)

Minimal PG example.

Changed 5 years ago by Ionic (Mihai Moldovan)

Attachment: devel_variantstest_Portfile added

Minimal port example.

comment:1 Changed 5 years ago by Ionic (Mihai Moldovan)

Description: modified (diff)

comment:2 Changed 5 years ago by Ionic (Mihai Moldovan)

Priority: NormalLow

Changing priority to low, this feature is likely not widely used and working around it is easy by directly looking at the Portfile in question. It's also not really breaking any functionality, as far as I can tell.

comment:3 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

I would have thought that attempting to define a variant more than once should be considered an error, and the resulting behavior would be undefined. Don't Do That™.

comment:4 Changed 5 years ago by Ionic (Mihai Moldovan)

Mh, I would have expected this to be a supported use case.

We have at least one PG that implements a variant - qmake-1.0. In such a case, merging the contents of the same-named variants (for instance because the PG implements the base code of a variant with more specific per-port code in the actual Portfile) would make sense.

It's not a new concept either, since you can also have multiple implementations for the same phase - which are then essentially merged together during execution - already. This is typically done with generic unconditional code and specialized one based on the platform or the like.

On the other hand, the qmake PG does look broken concerning this behavior, so maybe that's the actual problem. The qmake5 PG only adds a debug variant if it isn't already defined by the port, which probably was meant to be done in the qmake PG as well, but never carried it out correctly.

comment:5 Changed 5 years ago by Mihai Moldovan <ionic@…>

In 91b6be4b947ec0153f75d8eeab99597f23b37130/macports-ports (master):

qmake-1.0 PG: sync debug variant generation with qmake5-1.0 PG.

Adds a new option qt4.debug_variant - defaulting to yes, but the
PG-generated debug variant can be disabled by setting it to no.

Note that the variant checking code can stay in pre-extract, since it's
only checking information available in the database, not any actual file
location. Otherwise, it would have needed to be moved from pre-extract
to pre-configure in order to work correctly in trace mode, or if we ever
decide to implement something like background pre-fetching and
-extraction of ports.

See: #58229

Note: See TracTickets for help on using tickets.