[Insight-users] Re: itk java wrapper on cygwin problem (Progress)

[Brad King]

Gaëtan Lehmann wrote:
> I also have the same file with a very long name in my build tree, but I
> don't have any problem to access it. I thought this kind of problem was
> limited to windows (I say that but André didn't report any problem like
> that). What is you file system ?
> This kind of problem is already know and has been fixed for string lists
> and vectors in files Module/Base/*SwigExtras*.
> However, this workaround is inherited from the current ITK wrappers, and
> has not been modified in WrapITK - I'm not sure how it can be used to
> fix your problem.
> 
> Brad, can you help on that point ?
> 
> Le Tue, 25 Jul 2006 15:55:29 +0200, Michael Bell <michael.bell at acm.org>
> a écrit:
>> I am getting the following error while compiling (ITK&CableSwig 2.8):
>> Generating wrap_ITKCommonBaseJava.cxx
>> Unable to open
>> /data/WrapITK/Build_Linux/Java/InsightToolkit/SWIGTYPE_p_std___Rb_tree_iteratorTstd__pairTconst_std__basic_stringTchar_std__char_traitsTchar_t_std__allocatorTchar_t_t_itk__SmartPointerTitk__MetaDataObjectBase_t_t_std__pairTconst_std__basic_stringTchar_std__char_traitsTchar_t_std__allocatorTchar_t_t_itk__SmartPointerTitk__MetaDataObjectBase_t_tR_std__pairTconst_std__basic_stringTchar_std__char_traitsTchar_t_std__allocatorTchar_t_t_itk__SmartPointerTitk__MetaDataObjectBase_t_tp_t.java
>>
>> The file name is too long. Any ideas on how to correct this?

SWIG code is creating this long file name to hold code for basic
information about this non-wrapped type.  There are two ways around this:

1.) Find the type and wrap it so that it has a short wrapper name.

2.) Edit the ITK code to use something like

http://www.vtk.org/cgi-bin/viewcvs.cgi/Common/vtkStdString.h?view=markup

or an itk::StdString equivalent so that the type name is not so long.

>>> > It's pretty clear that no one is maintaining the wrappers with cygwin.
>>> > Please make this clear somewhere in the documentation so the next
>>> > person does not waste weeks on this, as I have.

If you want this to be maintained you can setup an ITK/WrapITK dashboard
entry with Cygwin.

>>> > So, we know that VS8 does not work.

GCC_XML should now support VS8.  What was the problem with it?

>>> >> SwigInc.txt contains a list of include paths:
>>> >> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Build_Cygwin
>>> >> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Code/Algorithms
>>> >> ...
>>> >> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Code/BasicFilters
>>> >> ^M
>>> >>
>>> >> Then, it has the ^M character at the end. If I remove this character,
>>> >> the xml file appears to be created correctly. Does anyone know where
>>> >> this is being created, or why, or how I can prevent it? Is this an
>>> ITK
>>> >> problem, or a CableSwig problem?

If you are building a source tree in cygwin with UNIX newlines you
should check out ITK from CVS using that cygwin's cvs command, or use
the source tarball instead of the .zip file.  Otherwise the source tree
has DOS newlines which is not compatible with cygwin UNIX newline mode.

I don't know why cygwin suggests UNIX newlines.  I always use the DOS
newlines mode and everything works fine.

-Brad