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

[Ryan Schmidt]

On Jul 28, 2011, at 17:55, Clemens Lang wrote:
> 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.

If you're going to install swig manually, you could put in anywhere other than /usr/local. Just /usr/local specifically is a problem. Therefore we shouldn't on the one hand (in our responses to user tickets, and in the FAQ / guide) tell the user never to put things in /usr/local, and on the other hand (in your configure script changes) tell the user to install swig there.

"/opt/swig" would possibly be a good choice and consistent with FHS.

http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES