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

Gaetan Lehmann gaetan.lehmann at jouy.inra.fr
Wed Jul 26 10:05:33 EDT 2006


On Wed, 26 Jul 2006 15:59:55 +0200, Michael Bell <michael.bell at acm.org>  
wrote:

> Gaetan,
>
> I am using ext3 on linux, which has a maximum filesize of 255
> characters. I see that Brad has addressed possible solutions to this.
>
> I commented out the MetaDataDictionary, and the rest of the compile
> finished without errors. Things seem to run well.

Great !
I'll try to fix that issue when I get some free time.

> I noticed that some
> classes are named differently than the straight itk wrapping. For
> example: itkImageMetricIF3 instead of itkImageMetricF3. Does the I
> stand for Image?

That's it
Several changes were made in the naming policy, to make it more  
expressive, for example, the I for an Image, VI for a VectorImage, ...

Let me know if you found other problems

Gaetan

>
> Thanks for your help,
> michael
>
> On 7/25/06, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>>
>> Hi,
>>
>> 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 ?
>>
>> As a quick fix, I think you should disable the class which use this  
>> type:
>> MetaDataDictionary.
>> To do that, just comment the line
>>
>>    WRAP_NON_TEMPLATE_CLASS("itk::MetaDataDictionary")
>>
>> in the file Modules/Base/wrap_ITKCommonBase.cmake
>> Taht being said, I think you will have the same problem with other types
>> used in more useful classes :-/
>> Let me now if it still fail (or if it work !)
>>
>> Gaetan
>>
>>
>> Le Tue, 25 Jul 2006 15:55:29 +0200, Michael Bell <michael.bell at acm.org>  
>> a
>> écrit:
>>
>> > Gaetan,
>> >
>> > I am trying wrapitk on linux while waiting to receive VS2003. I really
>> > like the setup, especially being able to choose what is wrapped.
>> >
>> > 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?
>> >
>> > thanks,
>> > michael
>> >
>> > On 7/19/06, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>> >>
>> >> Michael,
>> >>
>> >> André Bongers reported to be able to build WrapITK with the .NET 2003
>> >> c++.
>> >> WrapITK surely still have some bugs on windows plateform, but if you
>> >> want
>> >> to try it, I will surely be more reactive that official ITK  
>> developers.
>> >> WrapITK can be downloaded at
>> >>
>> >>    http://voxel.jouy.inra.fr/darcs/contrib-itk/WrapITK/WrapITK.tar.gz
>> >>
>> >> or directly with darcs
>> >>
>> >>    darcs get --partial
>> >> http://voxel.jouy.inra.fr/darcs/contrib-itk/WrapITK/
>> >>
>> >> and requires ITK 2.8.1
>> >>
>> >> Gaetan
>> >>
>> >>
>> >> Le Wed, 19 Jul 2006 22:10:55 +0200, Michael Bell  
>> <michael.bell at acm.org>
>> >> a
>> >> écrit:
>> >>
>> >> > SwigInc.txt is being generated from SwigInc.txt.in, which has the
>> >> > extra carriage return character. I suspect this is a problem  
>> because I
>> >> > am using the cygwin recommended unix files, but this file is a dos
>> >> > file. If I dos2unix SwigInc.txt.in and make, this error goes away,  
>> and
>> >> > all of the SwigIn.txt files are correct. If I run dos2unix on the
>> >> > entire Wrapping directory, many problems are fixed.
>> >> >
>> >> > Which shows the next issue:
>> >> > javac does not understand cygwin paths. This issue can be fixed  
>> using
>> >> > cygpath.
>> >> >
>> >> > Which shows the next problem:
>> >> > javac VXLNumericsJava.java
>> >> > cannot resolve symbol itkbase
>> >> >
>> >> > I haven't solved that problem, but I am certain it would reveal  
>> more.
>> >> >
>> >> > 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.
>> >> >
>> >> > So, we know that VS8 does not work. Cygwin does not work. What does
>> >> > work on Windows? I can change compilers, but I can't spend time
>> >> > hunting for a platform that does work. Please advise.
>> >> >
>> >> > thanks,
>> >> > michael
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 7/17/06, Michael Bell <michael.bell at acm.org> wrote:
>> >> >> ITK people,
>> >> >>
>> >> >> I have made some progress tracking down this error:
>> >> >> wrap_vnl_matrix.xml from gccxml_cc1plus:
>> >> >>  error: too many filenames given.  Type gccxml_cc1plus --help for
>> >> usage
>> >> >> make[2]: *** [Wrapping/CSwig/VXLNumerics/wrap_vnl_matrix.xml]  
>> Error 1
>> >> >>
>> >> >> This is the operation that fails (paths shortened for  
>> readability):
>> >> >> gccxml -fxml-start=_cable_ -fxml=wrap_vnl_matrix.xml
>> >> >> --gccxml-gcc-options SwigInc.txt -DCSWIG -DCABLE_CONFIGURATION
>> >> >> wrap_vnl_matrix.cxx
>> >> >>
>> >> >> 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?
>> >> >>
>> >> >> Please, I'm obviously willing to do the leg work, but it will  
>> take me
>> >> >> 10 times as long to figure this out than if an ITK developer would
>> >> >> step up and help. I've already shown that I was not the first  
>> person
>> >> >> to deal with this problem, and there are likely others who have  
>> not
>> >> >> said anything.
>> >> >>
>> >> >> thanks,
>> >> >> michael
>> >> >>
>> >> >>
>> >> >> --
>> >> >> michael.bell at acm.org
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Utilisant le client e-mail révolutionnaire d'Opera :
>> >> http://www.opera.com/mail/
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Utilisant le client e-mail révolutionnaire d'Opera :
>> http://www.opera.com/mail/
>>
>
>



-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr


More information about the Insight-users mailing list