I have another question now in addition to these: Why are there two pre-activate phases? The code I put in pre-activate gets executed in proc-pre-org.macports.activate-activate-0 and proc-pre-org.macports.activate-activate-1. (More below, from 'port install xcrysden') For writing a warning, it would be better not to have it written twice, as is currently happening.
Thanks, David :debug:install Found Dependency: path: /opt/local/lib/libgcc filename: libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$ :debug:activate activate phase started at Sun Oct 11 22:00:07 EDT 2015 :debug:activate Executing proc-pre-org.macports.activate-activate-0 :debug:activate Found Dependency: path: /opt/local/lib/libgcc filename: libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$ :debug:activate Active variants check for activate-type install considers depends_lib depends_run: fftw-3 mesa libGLU tcl tk xorg-libXmu xorg-libX11 xorg-libXext libgcc-devel BWidget :debug:activate tk is installed with the following variants: +quartz :debug:activate required: x11, forbidden: :debug:activate rejected, because required variant x11 is missing :msg:activate Warning: tk must be installed with +x11. :debug:activate Executing proc-pre-org.macports.activate-activate-1 :debug:activate Found Dependency: path: /opt/local/lib/libgcc filename: libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$ :debug:activate Active variants check for activate-type install considers depends_lib depends_run: fftw-3 mesa libGLU tcl tk xorg-libXmu xorg-libX11 xorg-libXext libgcc-devel BWidget :debug:activate tk is installed with the following variants: +quartz :debug:activate required: x11, forbidden: :debug:activate rejected, because required variant x11 is missing :msg:activate Warning: tk must be installed with +x11. :debug:activate Executing org.macports.activate (xcrysden) :msg:activate ---> Activating xcrysden @1.5.60_1+gcc5 On Sat, Oct 10, 2015 at 11:33 PM, David Strubbe <[email protected]> wrote: > > > On Sat, Oct 10, 2015 at 10:34 PM, Joshua Root <[email protected]> wrote: > >> On 2015-10-11 11:34 , David Strubbe wrote: >> > Thanks for checking. I realize now I can find these two different >> > behaviors, depending on whether the other dependency BWidget is >> > installed or not. I'm confused about why this would be happening. Why >> > isn't "Computing dependencies for xcrysden" happening in both cases? >> > >> > (BWidget is installed) >> > $ sudo port -f uninstall tk xcrysden >> > $ sudo port install xcrysden +x11 >> > ---> Computing dependencies for tk >> > ---> Fetching archive for tk >> > ---> Attempting to fetch tk-8.6.3_0+quartz.darwin_14.x86_64.tbz2 from >> > http://mse.uk.packages.macports.org/sites/packages.macports.org/tk >> > ... >> > >> > $ sudo port -f uninstall tk xcrysden BWidget >> > $ sudo port install xcrysden +x11 >> > ---> Computing dependencies for xcrysden >> > ---> Dependencies to be installed: BWidget tk >> > ---> Fetching archive for tk >> > ---> Attempting to fetch tk-8.6.3_0+x11.darwin_14.x86_64.tbz2 from >> > http://mse.uk.packages.macports.org/sites/packages.macports.org/tk >> > ... >> >> It happens in both cases, you just stopped before it got there in the >> first case. Already-installed dependencies are upgraded before new >> dependencies are installed. >> > > I did not stop anything; I just included only the important parts (hence > "..."). Yes it does say "Computing dependencies for xcrysden" eventually in > the first case, but why is it after have installed a dependency? Surely the > dependencies were computed at the beginning anyway to decide to install tk. > > I think you are suggesting it is related to the fact that tk is a > dependency of BWidget. It's hard to understand why that would matter for > what variant got passed to tk. > > >> >> > Regarding the pre-activate, I added this code to my copy of >> > active_variants-1.1.tcl: >> > >> > +pre-activate { >> > + ui_warn "checking active variants" >> > + _check_require_active_variants archivefetch >> > +} >> > >> > When I do a fresh install, I see this message before activate. When I >> > deactivate and re-activate, I don't see the message. My conclusion was >> > that pre-activate was not being run in the latter case -- is there some >> > other reason it wouldn't be written? >> >> Are you editing the portgroup after you install the port? Running a >> target on an already installed port uses the copy of the portgroup >> stored in the registry. >> > > Before I installed the port. I am running "port install" in the directory > with the Portfile, then "port deactivate", then "port activate" (in each > case, not specifying a name). Does that still just use the registry > portgroup rather than the one in my dports tree? >
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
