passing variants to dependencies; pre-activate check

[Joshua Root]

On 2015-10-11 09:33 , David Strubbe wrote:
> Hi all,
> 
> It seems to me that as of recently it was the case that variants from
> the install command line are passed on to the building of dependencies
> (as discussed below last year), but that it is no longer happening. Is
> this something that was changed (deliberately or otherwise) in the 2.3.4
> release?
> 
> Specifically, my recently added xcrysden port needs tk +x11 (checked via
> active_variants), whereas the default is +quartz. As of a couple of
> weeks ago, I think I was able successfully to trigger installation of tk
> +x11 when it was not installed by doing 'port install xcrysden +x11'.
> But now this doesn't happen.

I just checked and this still works the same as it has for many years.

> Another question related to active_variants: would it be possible for
> require_active_variants to perform its check not just in the
> pre-configure phase as is currently the case, but also in the activate
> phase? Currently, you could install xcrysden when tk +x11 was active,
> then deactivate xcrysden, install tk +quartz, and re-activate xcrysden.
> It would no longer work. It would be good if we could write an error at
> this point. I tried adding code to pre-activate to accomplish this, but
> I found it was only called when doing a fresh install, not when
> activating a deactivated port. Is there a way to get some code to run
> when activating a deactivated port?

Preventing the activation would not be helpful I think, especially if
the user is running something like 'port activate xcrysden tk +x11'.
Printing a warning would be fine.

I just checked the pre-activate behaviour as well and it still runs
before every activation as intended. The only reason it wouldn't run is
if the Portfile was missing from the registry or failed to parse.

- Josh