[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITK debian packages



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.

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)


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@")


I then built the insighttoolkit sources with python wrappers using
this cableswig.  The build is complete, but I have not tested it.


One refinement you can make is to completely omit GCC and GCC_XML 
from the source.

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?


Regards,
-Steve



Reply to: