Hi Steve, ... and g'day Brad! I've CC'ed you as this thread is all about CableSwig and packaging.
Quick summary: I've packaged CableSwig 2.4 for Debian, Steve has now packaged GCC_XML separately and managed to get CableSwig to use this standalone package. So I guess the question becomes: is the source for GCC_XML included with CableSwig patched at all from the original, or can we just use the upstream sources as is? On Sun, 2006-01-22 at 12:23 -0500, Steve M. Robbins wrote: > On Fri, Jan 20, 2006 at 05:51:05PM -0500, Steve M. Robbins wrote: > > > However, the binaries in question are those of gcc-xml which you agree > > should be packaged separately anyway. So the question now is more > > like: can cableswig be built to use an external gcc-xml? > > I'm pleased to report that it can be. Excellent - thanks for that! > I uploaded gccxml package yesterday. It's new and currently awaiting > approval, > but you can fetch a copy from http://people.debian.org/~smr/gccxml/ > > Then there are two changes that need to be done to cableswig to use > the external gccxml package. > > 1. Don't build GCC and GCC_XML: > > diff -u -b -B -r1.20 CMakeLists.txt > --- CMakeLists.txt 7 Jun 2005 13:34:18 -0000 1.20 > +++ CMakeLists.txt 22 Jan 2006 17:14:28 -0000 > @@ -80,7 +80,7 @@ > # Tell GCC-XML where to install. > SET(GCCXML_INSTALL_ROOT ${CableSwig_INSTALL_ROOT}/lib/CableSwig) > > -SUBDIRS(SWIG Cable GCC GCC_XML Executables) > +SUBDIRS(SWIG Cable Executables) Okay, we can probably even make this a configurable option in the CMake config file, so you can enable/disable using the built-in GCC_XML. > 2. Use "/usr/bin/gccxml" in the CableSwigConfig.cmake. I tried to do > this by fiddling with debian/CMakeCache.txt.debian or setting on the > cmake command line, but failed. So here's the crude way to do this: > > diff -u -b -B -r1.2 CableSwigConfig.cmake.in > --- CableSwigConfig.cmake.in 16 Jun 2004 14:39:03 -0000 1.2 > +++ CableSwigConfig.cmake.in 22 Jan 2006 17:19:24 -0000 > @@ -4,5 +4,5 @@ > > SET(CableSwig_cableidx_EXE "@CableSwig_cableidx_EXE_CONFIG@") > SET(CableSwig_cswig_EXE "@CableSwig_cswig_EXE_CONFIG@") > -SET(CableSwig_gccxml_EXE "@CableSwig_gccxml_EXE_CONFIG@") > +SET(CableSwig_gccxml_EXE "/usr/bin/gccxml") > SET(CableSwig_DEFAULT_LIB "@CableSwig_DEFAULT_LIB_CONFIG@") Okay, I think there's a prefix variable we can use in there. Will check that too. > I then built the insighttoolkit sources with python wrappers using > this cableswig. The build is complete, but I have not tested it. Great. Just wondering; how long did it take? > One refinement you can make is to completely omit GCC and GCC_XML > from the source. Sure, will do (assuming it is the same as upstream). > Also I noticed that cableswig has never been released and you have > to pull it from CVS. You packaged it with the ITK release number > (2.4); is that what the ITK folks recommend? Or should we use a > CVS version scheme, e.g. 0+cvs20060122? CableSwig does actually have an official release of 2.4. It is released simultaneously with ITK, and the versions are in step. It is available in tarball and zip format from: http://www.itk.org/HTML/Download.htm I'll grab your source and start making the changes discussed above, hopefully with some insight from Brad. Thanks much - regards, :: Gavin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
