$ make frameworkinstall DESTDIR=[...]/py3_1rc1-macosx-apy31-rrun/image
running install_scripts
[...]
copying build/scripts-3.1/2to3 ->
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin
error:
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3:
Too many levels of symbolic links
make: *** [sharedinstall] Error 1


!
!

this appears to be a regression in 3.1rc1 (used to work with 3.1b2).
need to investigate further. will update this bug if I find anything
useful. (quick observation .. 'install_scripts' seem to be run twice)

To explain further, the following section of script is run *twice* .. 
and thus explains the error "Too many levels of symbolic links"

mv 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3" 
"[...]]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3-3.1"
ln -sf 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3-3.1" 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3"

The entire log file is here: http://double.activestate.com/t/apy31-anole.log

On 09-06-01 04:46 PM, Sridhar Ratnakumar wrote:
> >
> > make: [image_python] PythonLauncher build attempt 1 of 2 (see bug 44709)
> > make: [image_python] running 'cd build/py3_1rc1-macosx-apy31-rrun/python
> > &&  make frameworkinstallapps
> >
DESTDIR=/Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image'
> > [...]
> > make: [image_python] running 'cd build/py3_1rc1-macosx-apy31-rrun/python
> > &&  make frameworkinstall frameworkinstallextras
> >
DESTDIR=/Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image'
> > [...]
> >
> >
> > Note: the second make attempt uses 'frameworkinstallextras' as the extra
> > argument.
> >
> > .
> > .
> >
> > This appears to be breaking 3.1rc1 on Mac ("Too many levels of symbolic
> > links"):
> >
> > running install_scripts
> > [...]
> > copying build/scripts-3.1/2to3 ->
> >
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin
> > error:
> >
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3:
> > Too many levels of symbolic links
> > make: *** [sharedinstall] Error 1

Tarek, are you perchance aware of any change that went into distutils
since the last beta release that could have influenced the make behavior?

No, but I am running frameworkinstall right now under Mac to see if I
can reproduce the problem

To help with the repro, may I suggest running the following in the same
order:

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image

I'll try tomorrow asap (sorry it's 2:30 am now here)

also related to issue 5756

The URL you provide for the log doesn't seem to be accessible externally 
so it is difficult to guess exactly what was being done.  However, there 
were changes between 3.1b2 and 3.1rc1 to the top-level Makefile 
(Makefile.pre.in) and to the Mac/Makefile.in affecting framework builds 
and installs.

Sorry I can't reproduce it,

can you tell me how you run configure precisely ?
eg the whole set of commands after a fresh checkout

I also cannot reproduce this, using both the py3k branch and the r31rc1 
tag. 

My build procedure:

* cd r31rc1
* mkdir build
* cd build
* ../configure --enable-framework --enable-universalsdk
* make
* make install DESTDIR=$PWD/image

The resulting framework in the $DESTDIR seems to be complete, and I 
don't get errors while building it.

Now I'm really confused, I tried  to install a second time and this time I 
do get an error. 

Time to start hunting down an issue...

Ronald, did you try Sridar precise sequence after Pyhon was built ?

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image

Manually running "make frameworkinstallframework" (and the other ones) is 
not supported, those are internal makefile targets that are are used to 
implement "make install". 

"make framworkinstall" is supported as an alias for "make install" because 
the former was the only way to install a framework for a long time.

I found the issue.

In r72899 antoine.pitrou checked in a change that adds these two lines 
to the bininstall target in Makefile.pre.in:

   -rm -f $(DESTDIR)$(LIBPC)/python3.pc
   (cd $(DESTDIR)$(LIBPC); $(LN) -s python-$(VERSION).pc python3.pc)

This exposes a bug in the configure script, which causes target 
'bininstall' to run before 'libainstall' when your doing a framework 
install.  The latter target is the one that creates python-
$(VERSION).pc, which is why we get build failures.

What I don't understand is why I've been able to install frameworks all 
along and didn't notice this before. 

I'm working on a patch, and will check that in after I've full tested 
it.

The important bit of the patch is this change to configure.in:

-		FRAMEWORKALTINSTALLFIRST="frameworkinstallstructure 
bininstall maninstall"
+		FRAMEWORKALTINSTALLFIRST="frameworkinstallstructure "

This should be fixed in r73142, please test.

That seems to work.  However, while testing that, I found another, minor 
problem in that same area.  In Makefile.pre.in bininstall target just 
before the lines you cite, there is also this added in r71935:

-rm -f $(DESTDIR)$(BINDIR)/python3-config
(cd $(DESTDIR)$(BINDIR); $(LN) -s python$(VERSION)-config python3-
config)

Prior to that, though, the Mac Makefile target install_versionedtools is 
mucking in the same area:

if [ ! -h "$(DESTDIR)$(prefix)/bin/python3-config" ]; then \
  mv "$(DESTDIR)$(prefix)/bin/python3-config" 
"$(DESTDIR)$(prefix)/bin/python$(VERSION)-config" ;\
  ln -sf "python$(VERSION)-config" "$(DESTDIR)$(prefix)/bin/python3-
config" ; \
fi

and, in fact, the mv fails with an error because (1) the python3-config 
hasn't been created yet and (2) the test is incorrect: ! -h is also true 
if the file doesn't exist.  With the code in bininstall, I think these 
lines can be safely removed from install_versionedtools.

Ronald, a quick note - your fix unfortunately did not solve the issue.

[quote]'To help with the repro, may I suggest running the following in
the same
order:

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image
'[endquote[

Don't do that, use 'make install DESTDIR=$PWD/image'. As I mentioned 
earlier 'make frameworkinstallframework' is an internal step that 
shouldn't be used on its own.

Ok, I am no longer relying on internal targets .. and this problem is 
fixed for me. It needs to be closed, correct?