tcl needs --disable-corefoundation

[Jack Howarth]

On Sun, Oct 11, 2009 at 08:40:12PM -0400, Jack Howarth wrote:
> On Sun, Oct 11, 2009 at 11:51:26PM +0200, Rainer Müller wrote:
> > On 2009-10-11 22:44 , Jack Howarth wrote:
> > >     Am I correct in assuming that it is best practices to
> > > construct packaging that builds against python25 or python26
> > > without requiring the associated python to be activated?
> > > I believe the current pymol packaging should now build
> > > regardless of the activation state of python26 with the above
> > > change.
> > 
> > Any file in the prefix comes from an active port. Inactive ports are
> > "invisible" and cannot be used from other ports.
> > 
> > See <http://guide.macports.org/#internals.images>
> > 
> > Rainer
> 
> Rainer,
>     The current behavior seems really confused. For example, if I have
> python25 and python26 installed but only python26 activated, I can
> install py25-setuptools with out errors being reported. However, if
> I execute...
> 
> sudo port install py25-pmw
> 
> I get an error...
> 
> DEBUG: Found Dependency: receipt exists for python26
> --->  Activating py25-pmw @1.3.2_1
> DEBUG: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py is being used by the active py26-pmw port.  Please deactivate this port first, or use 'port -f activate py25-pmw' to force the activation.
>     while executing
> "_activate_contents $name $imagefiles $imagedir"
>     (procedure "portimage::activate" line 56)
>     invoked from within
> "registry_activate $name ${version}_${revision}${portvariants} [array get user_options]"
>     (procedure "eval_targets" line 21)
>     invoked from within
> "eval_targets activate"
>     invoked from within
> "$workername eval eval_targets $target"
>     (procedure "mportexec" line 85)
>     invoked from within
> "mportexec $workername $target"
> 
> If I follow the recommendation and execute...
> 
> sudo port -f activate py25-pmw
> 
> I get errors...
> 
> Warning: File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py already exists.  Moving to: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py.mp_1255307467.
> etc.
> 
> The logic of maintaining multiple pythons seem horribly convoluted and very
> fragile (at least if you follow the recommendations in the error messages).
> Wouldn't it be better to just have any Portfile that needs access to python25
> or python26, explicitly depend on it and, if not activated, allow port to request
> for and implement the activation in real time during the build?
>            Jack
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

On reflection, it seems to me that port should attempt to make
the activate/deactivate behavior mimic how Build-Depends are
handled in fink/debian for *-dev packages. For example, if a
package needs to be built against python25 in MacPorts and
python26 is activated, port should temporarily activate
python25 for the duration of the package build and then
restore the previous activation state on exiting the installation.
As far as I can see, the core files of python25 (for running
programs that directly access /opt/local/bin/python2.5) are all
present for packages built this way to continue to run despite
python25 being deactivated after the build.
              Jack
ps So the activatation state of python25 vs python26 could be
considered to analogous to the Conflicts in python25 and
python26 fink packages. There is no reason this situation
shouldn't be automated in the same fashion so that when
a package requires python25 to be activated, it is done
automatically during the build but isn't a permanent change.