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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev