On Dec 6, 2012, at 03:05, Aljaž Srebrnič wrote: >> On a side note, why does the active_variants portgroup require the consumer >> to enclose the require_active_variants invocation in a post-configure block? >> Why can't the portgroup do that on its own, like the conflicts_build >> portgroup does? Anyway shouldn't it be pre-configure not post-configure? > > well, the only difference between putting the code in pre-configure and > post-configure is, well, that configure gets executed, so pre-configure > should save some time.
My thought was that it was not only time savings, but also possible error avoidance. The way it is now, assume cairo is not installed with the quartz variant. py27-cairo's configure will run (which will find out about the currently-installed cairo without quartz support), and afterward, the active_variants portgroup will display the error to the user and exit. The user will follow the instructions and reinstall cairo with the quartz variant and will then retry the py27-cairo installation, which, assuming the user does not clean py27-cairo first, will pick up where it left off. The configure phase hadn't completed, so it will run again, but I don't know whether configure will re-check everything again or whether it caches the results of prior runs somewhere. > I don't know why it has to be put in *-configure, The comments in the portgroup explain that. Before the configure phase, you can't be sure that the dependencies have been installed at all. For example if you just run "port info py27-cairo" MacPorts won't install any dependencies for you. Or if you run "sudo port extract py27-cairo" MacPorts will only install fetch and extract dependencies, but not build, lib or run dependencies. > but we can always change the portgroup... Yes, I suppose I should be asking Clemens (Cc'd now) about this since he wrote the portgroup. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
