Re: ITK debian packages
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
Reply to: