Re: [Visualpython-users] vpython fink package for Mac OSX 10.3

[Martin C. <cos...@wa...>]

Jonathan Brandmeyer wrote:


> Excellent, I got it.  I have a build going as I write this on a 10.2 box
> with Python 2.2 and an Apple-distributed GCC 3.1.

Yes, I found now that the error I am seeing comes from using gcc-3.3 
which is the standard on OSX 10.3. It goes away when I use gcc-3.1. It 
seems that the CXX library does not work with gcc-3.3. This is really 
weird, because all these things are in the end linked with the python2.3 
executable which was compiled with gcc-3.3, and C++-compiled binaries 
are, in general, not compatible between gcc-3.1 and gcc-3.3.

Anyway, if no solution is found to make the CXX stuff compatible with 
gcc-3.3, I can require that the package is built with gcc-3.1, crossing 
fingers that this will not break other things.

> First off, unless you have CPPFLAGS set to include -I/sw/include already
> as part of the fink environment, it should be set by visual-py23.info.

This is automatically set by fink.

> cvisual/Makefile is totally insensitive to the DESTDIR variable, exactly
> why is it needed?  Is the makefile not picking up on the value of
> 'prefix' for some reason?

It is, but the fink build process is like with debian or rpm: You don't 
install to the final destination, but to some build-root from which the 
package is then created. Thus the prefix is set to /sw (%p in the info 
file), but the make install has to install into 
/sw/src/root-visual-py23-2.1.9-1/sw/

Hence the need for the DESTDIR variable which is respected in all 
subdirectories except cvisual. cvisual/Makefile installs the vpython 
script directly into /sw/bin which is illegal, because in this way it 
does not get into the package.

> Since gtkglarea is distributed as a static lib, I think it should
> actually be a build-dependency and not an install dependency.

OK, noted.

> With the changes that your patch makes to OSX_SORULE, the link step
> fails with many undefined references to functions defined in the Python
> executable itself.

The "-bundle_loader $PYTHON" flag takes care of this. It tells ld to 
look for undefined symbols in the python executable. There was just a 
syntax error: -bundle_loader doesn't take a "=" sign. I removed the 
-flat_namespace, because the python executable is compiled as a 
two_level binary, but I guess this doesn't make much difference.
In any case, it compiled OK for me, both with gcc-3.3 and with gcc-3.1.

> Just exactly what does that sed script do?  I've never used sed.

This is something completely unimportant. I wanted to have something 
other than the license.txt in the doc directory. For every fink package 
there is a doc directory in /sw/share/doc, in this case 
/sw/share/doc/visual-py23. I took the docs/index.html to put there, 
renamed to visual.html, and the sed changes the links in that file so 
that they point to the other local vpython html files in 
/sw/lib/python2.3/site-packages/visual/docs. I don't know enough about 
the inner workings of vpython to see whether the latter need to remain 
in the site-packages/visual/docs directory or whether they could be 
moved to /sw/share/doc/visual, so I let them where they were installed 
by default.

> What command do you execute to build the package? (eg, the counterpart
> to dpkg-buildpackage in Debian).

The command is simply "fink install visual-py23". Fink actually creates 
a *.deb package and then uses dpkg to install it at its final 
destination. If one wants to build only the deb package without 
isntallation, the command is "fink build visual-py23".

The package will first go into the unstable tree, so that fink users 
will have to activate this. After some time, it will migrate to the 
stable tree, and in this case it can then become part of Fink's binary 
distribution. When this is achieved, Fink users can use "apt-get install 
visual-py23" to get the precompiled binary directly.

> visual/Makefile byte-compiles site-packages/visual/*.py already, why is
> the post-install script doing this as well?

I saw that the *.pyc files have the buildroot directory hardwired inside 
and suspected that this could have something to do with my error, so I 
compiled them a second time after they were installed at their final 
place. But I think this is useless, after all. OK, while I wrote this, I 
compiled it again without this PostInstScript, and the ball is still 
bouncing, so I guess I'll remove this part.

Another question: I read Kelvin Chu's installation instructions, and he 
says that gdbm3 is needed, too. Is this true? I don't see anything 
gdbm-related in the compile log.

-- 
Martin