passing variants to dependencies; pre-activate check

[David Strubbe]

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.

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?

Thanks,
David

On Sun, Nov 16, 2014 at 6:40 PM, Lawrence Velázquez <larryv at macports.org>
wrote:

> On Nov 16, 2014, at 5:32 PM, David Strubbe <dstrubbe at macports.org> wrote:
>
> > All right, but can you clarify about default variants: is it true that
> default variants are not passed to dependencies, but all other variants
> are? And, is there any good reason for this? It would solve my problem
> immediately if they were passed on.
>
> As far as I know, variants are only passed from the command line, and even
> then they are only applied when dependencies have to be installed. Running
>
>     port install foo
>
> where foo has some default variant +bar is *not* equivalent to running
>
>     port install foo +bar
>
> I don't know the reason for this behavior.
>
> vq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20151010/f69c246c/attachment-0001.html>