[81252] branches/gsoc11-rev-upgrade/base

[Clemens Lang]

On Thu, Jul 28, 2011 at 05:37:09PM -0500, Ryan Schmidt wrote:
> Please please please no. We extremely do not want MacPorts users
> installing anything in /usr/local. We constantly tell users not to do
> this because we constantly receive bug reports from users who have
> things installed there which are causing problems.

First: This is only necessary if you work on machista.i, which will
force the Makefile to re-generate machista_wrap.c. If you don't modify
it (and/or) have MacPorts configured without swig (which is possible)
make clean will not delete the file and it will always be more current
than it's source file machista.i (because I added the generated code to
subversion). Swig won't have to be called to build MacPorts and the
typical user compiling from source will never see this message.

Having said that, the situation is less than optimal. Apple stopped
shipping swig with Lion (SL did come with /usr/bin/swig, version 1.3.31
I think), installing swig-tcl with some other MacPorts installation
gives you swig 2.x, which can be used by
	SWIG=$PREFIX/bin/swig ./configure --your-other-options
(remember you shouldn't have MacPorts in your $PATH when configuring
MacPorts, at least that's what I've been told). However, calling swig on
machista.i generates code that does currently not compile warning free,
because it apparently tries to cast Tcl ClientData (which is esentially
void*) to a function pointer and vice-versa, which is forbidden by the
standard (because function and data pointers used to have different
sizes). I'm planning to contact the swig team and try to resolve this
issue (e.g. by wrapping the function pointer in a struct).

So, if everything works out fine, I'm the only person that should need
to have a swig 1.x in /usr/local.

Suggestions for other practical and clean solutions welcome.

-- 
Clemens Lang
GSoC Student